সর্বদা এনভারচার (ম্যাক্স) ব্যবহারের কোনও অসুবিধা আছে কি?

342

এসকিউএল সার্ভার ২০০৫-তে, সমস্ত অক্ষর ক্ষেত্রকে এনওয়ারচর (ম্যাক্স) তৈরির পরিবর্তে কোনও দৈর্ঘ্য স্পষ্টভাবে উল্লেখ করার চেয়ে কোনও অসুবিধা আছে কি না, যেমন এনভারচর (255)? (আপনি ডেটাবেস পর্যায়ে মাঠের দৈর্ঘ্য সীমাবদ্ধ করতে সক্ষম নন এমনটি স্পষ্টতাকে বাদে)

sql  sql-server  sql-server-2005 
— stucampbell
সূত্র
1
আমি বুঝতে পারি না কেন আপনি কাউকে 8000+ অক্ষরের নামে প্রবেশ করতে দিতে চান।
— ডিফোক 42
2
একই যুক্তি প্রোগ্রামিং ভাষার ক্ষেত্রে প্রয়োগ করা যেতে পারে। আমাদের সমস্ত ডেটার জন্য কেন পুরাতন ভিবি 6 বৈকল্পিকটিতে ফিরে যাবেন না? আমি মনে করি না যে একাধিক জায়গায় চেক এবং ব্যালেন্স থাকা খুব খারাপ।
— ম্যাট স্প্রেডলি
1
— আকিরা ইয়ামামোটো
10
আপনার আপডেটটি এই প্রশ্নের নিজস্ব উত্তর হতে হবে।
— জোহান
মূল লেখক এটি করেন নি বলে উত্তর-প্রশ্ন যথাযথ উত্তরে চলে গেছে। stackoverflow.com/a/35177895/10245 আমার 7 বছরের চিত্রের যথেষ্ট সময় রয়েছে :-)
— টিম আবেল

উত্তর:

153

এমএসডিএন ফোরামে একই প্রশ্ন জিজ্ঞাসা করা হয়েছিল:

মূল পোস্ট থেকে (সেখানে আরও অনেক তথ্য):

আপনি যখন কোনও ভিচারার (এন) কলামে ডেটা সঞ্চয় করেন, মানগুলি শারীরিকভাবে একইভাবে সংরক্ষণ করা হয়। তবে আপনি যখন এটি কোনও ভ্রচার (ম্যাক্স) কলামে সঞ্চয় করেন, তখন পর্দার পিছনে ডেটাটি একটি পাঠ্য মান হিসাবে পরিচালনা করা হয়। সুতরাং কোনও ভ্রচার (ম্যাক্স) মান নিয়ে কাজ করার সময় কিছু অতিরিক্ত প্রসেসিং প্রয়োজন। (কেবলমাত্র আকার 8000 ছাড়িয়ে গেলে)

ভর্চার (ম্যাক্স) বা এনভিচারার (ম্যাক্স) একটি 'বৃহত মান ধরণের' হিসাবে বিবেচিত। বড় মানের ধরণগুলি সাধারণত 'সারি বাইরে' সঞ্চিত থাকে। এর অর্থ হ'ল ডেটা সারিতে অন্য স্থানে পয়েন্টার থাকবে যেখানে 'বৃহত্তর মান' সঞ্চয় করা আছে ...

— ডেভিড ক্রেপস
সূত্র
2
সুতরাং প্রশ্নটি হওয়া উচিত, এন / ভিআরচার (ম্যাক্স) এবং এন / টেক্সট ব্যবহারের মধ্যে কোনও পার্থক্য আছে কি?
— অপ্রকাশিত
18
আমি যদি সঠিকভাবে স্মরণ করি তবে আকারটি 8 কে ছাড়িয়ে গেলে সেগুলি কি কেবল সারির বাইরে সংরক্ষণ করা হয় না?
— স্যাম শ্যুট
79
আমি উত্তরটি "না, N/VARCHAR(MAX)" ব্যবহারের কোনও অসুবিধা নেই কারণ "অতিরিক্ত প্রক্রিয়াকরণ রয়েছে" কেবল তখনই আকারটি 8000 ছাড়িয়ে যায় " হিসাবে পড়েছি । সুতরাং, যখন প্রয়োজন হয় তখনই আপনি ব্যয় করতে হয় এবং আপনার ডাটাবেসটি কম সীমাবদ্ধ । আমি কি এই ভুল পড়ছি? দেখে মনে হচ্ছে আপনি প্রায় সবসময় N/VARCHAR(MAX)চেয়ে N/VARCHAR(1-8000)
— চেয়েছিলেন
1
উপরে মৃত লিঙ্ক - দুটিই MSDN প্রশ্ন জন্য কাজ লিঙ্ক social.msdn.microsoft.com/Forums/en-US/sqlgetstarted/thread/...
— Jagd
68
দুর্ভাগ্যক্রমে এই উত্তরটিতে বেশ কয়েকটি সমস্যা রয়েছে। এটি 8 কে বাউন্ডারিটিকে ম্যাজিক সংখ্যার মতো মনে করে, সত্য নয়, মান আরও বেশি কারণের উপর ভিত্তি করে সারি থেকে সরে যায়, এর মধ্যে রয়েছে sp_tableoptions: এমএসডিএন.মাইক্রোসফট /en-us/library/ms173530.aspx । VARCHAR (255) প্রকারগুলিও সারির বাইরে ধাক্কা দিতে পারে, উল্লিখিত 'ওভারহেড' MAX এবং 255 এর জন্য হুবহু একই হতে পারে X এটি MAX প্রকারের সাথে টেক্সট প্রকারের সাথে তুলনা করে, যখন এটির সাথে আলাদা হয় (ম্যানিপুলেট করার জন্য সম্পূর্ণ পৃথক এপিআই, বিভিন্ন স্টোরেজ ইত্যাদি)। এটি প্রকৃত পার্থক্য উল্লেখ করতে ব্যর্থ: কোনও সূচক নয়, ম্যাক্স ধরণের উপর কোনও অনলাইন অপারেশন নেই
— রিমাস রুসানু
50

এটি একটি সুস্পষ্ট প্রশ্ন এবং তিনি স্পষ্টতাকে বাদ দিয়ে বলেছেন ...

অসুবিধাগুলি অন্তর্ভুক্ত করতে পারে:

পারফরম্যান্সের ইমপ্লিকেশনস কোয়েরি অপ্টিমাইজার সবচেয়ে কার্যকরী এক্সটেকশন পরিকল্পনা নির্ধারণের জন্য ক্ষেত্রের আকার ব্যবহার করে

"১. ডাটাবেসের প্রসারিত এবং পৃষ্ঠাগুলির মধ্যে স্থান বরাদ্দ নমনীয় Thus সুতরাং আপডেটটি ব্যবহার করে ক্ষেত্রের সাথে তথ্য যুক্ত করার সময়, নতুন ডেটা যদি আগের thanোকানো থেকে দীর্ঘ হয় তবে আপনার ডাটাবেসটি একটি পয়েন্টার তৈরি করতে হবে This এই ডাটাবেস ফাইলগুলি খন্ড খন্ড হয়ে ছড়িয়ে পরিণত = প্রায় সবকিছুই কর্মক্ষমতা কমে মুছে ফেলতে সূচক, আপডেট এবং টিপে থেকে। " http://sqlblogcasts.com/blogs/simons/archive/2006/02/28/Why-use-anything-but-varchar_2800_max_2900_.aspx

ইন্টিগ্রেশন সম্পর্কিত বিষয়গুলি - আপনার ডাটাবেসের সাথে কীভাবে সংহত করতে হবে তা অন্যান্য সিস্টেমের পক্ষে শক্ত data ডেটাটির অবিশ্বাস্য বিকাশ সম্ভাব্য সুরক্ষা সমস্যাগুলি যেমন আপনি সমস্ত ডিস্কের স্থান গ্রহণ করে কোনও সিস্টেম ক্র্যাশ করতে পারেন

এখানে ভাল নিবন্ধ আছে: http://searchsqlserver.techtarget.com/tip/1,289483,sid87_gci1098157,00.html

— alexmac
সূত্র
4
ইন্টিগ্রেশন এবং সুরক্ষা জড়িতগুলির জন্য +1। অন্যান্য উত্তরগুলি যখন কার্য সম্পাদন সম্পর্কে কথা বলে তখন এগুলি বিবেচনার জন্য একটি মূল কোণ। ইন্টিগ্রেশন সম্পর্কিত প্রভাব সম্পর্কিত যে কোনও সরঞ্জাম (যেমন রিপোর্ট লেখক বা ফর্ম ডিজাইনার) যুক্তিযুক্ত ডিফল্ট কন্ট্রোল আকারের জন্য মেটা ডেটা ব্যবহার করে যদি সমস্ত কলাম থাকে তবে ব্যবহার করতে আরও অনেক বেশি কাজ প্রয়োজন varchar(max)।
— বিভ্রান্ত
ডেটাবেস দ্বারা একীকরণ সবচেয়ে হাস্যকর জিনিস আমি জানি। এটি একবারে আমদানি হয়ে গেলে আপনি আগে LEN ফাংশন দ্বারা ডেটা পরীক্ষা করতে পারেন।
— ম্যাক্সিম
30

গৃহীত উত্তরে প্রদত্ত লিঙ্কের ভিত্তিতে এটি প্রদর্শিত হয়:

  1. একটি nvarchar(MAX)ক্ষেত্রের মধ্যে সংরক্ষণ করা 100 টি অক্ষর কোনও nvarchar(100)ক্ষেত্রে 100 টির চেয়ে আলাদা অক্ষরের মধ্যে সংরক্ষণ করা হবে - ডেটা ইনলাইন সংরক্ষণ করা হবে এবং আপনার কাছে 'সারির বাইরে' ডেটা পড়ার এবং লেখার ওভারহেড থাকবে না। সুতরাং সেখানে কোনও উদ্বেগ নেই।

  2. যদি আকার 4000 এর বেশি হয় তবে ডেটা স্বয়ংক্রিয়ভাবে 'সারি বাইরে' সংরক্ষণ করা হবে, যা আপনি চাইবেন। সুতরাং সেখানে কোন উদ্বেগ নেই।

যাহোক...

  1. আপনি কোনও nvarchar(MAX)কলামে সূচি তৈরি করতে পারবেন না । আপনি পূর্ণ-পাঠ্য ইনডেক্সিং ব্যবহার করতে পারেন, তবে ক্যোয়ারি পারফরম্যান্স উন্নত করতে আপনি কলামে একটি সূচক তৈরি করতে পারবেন না। আমার জন্য, এই চুক্তিটি সিল করে ... সর্বদা nvacharhar (MAX) ব্যবহার করা এটি একটি নির্দিষ্ট অসুবিধা।

উপসংহার:

আপনি যদি আপনার পুরো ডাটাবেস জুড়ে এক ধরণের "সর্বজনীন স্ট্রিং দৈর্ঘ্য" চান, যা সূচী করা যায় এবং যা স্থান এবং অ্যাক্সেসের সময় নষ্ট করে না, তবে আপনি ব্যবহার করতে পারেন nvarchar(4000)।

— টিম এবেল
সূত্র
1
fyi এটি মূল প্রশ্নের সাথে যুক্ত একটি সম্পাদনা যা উত্তর হিসাবে পোস্ট করা উচিত ছিল
— টিম আবেল
1
ধন্যবাদ, আমার জন্য এটি চূড়ান্ত উত্তর। আমি নিজেকে জিজ্ঞাসা করেছি - কেন সবসময় ব্যবহার করবেন না nvarchar(max)- stringসি # এর মতো? - তবে পয়েন্ট 3) (সূচক ইস্যু) উত্তর দিচ্ছে।
— এসকিউএল পুলিশ
1
একটি সম্পাদনা যুক্ত করা হয়েছে। একধরনের "সার্বজনীন স্ট্রিং দৈর্ঘ্য" হিসাবে, আপনি সর্বদা ব্যবহার করতে পারেনnvarchar(4000)
— এসকিউএল পুলিশ
@ এসকিউএল জিওর্জ কলামগুলি আগের চেয়ে আরও বিস্তৃত ঘোষণা করার পারফরম্যান্সের প্রশ্নের বিষয়ে মার্টিন স্মিথের এই দুর্দান্ত উত্তরটি দেখুন
— বিলিংক
@ বিলিংক ধন্যবাদ, এটি একটি দুর্দান্ত নিবন্ধ। ঠিক আছে, তাই আকারটি প্রকৃতপক্ষে পারফরম্যান্সকে প্রভাবিত করে। আমি আবার উত্তর সম্পাদনা করব।
— এসকিউএল পুলিশ
28

কখনও কখনও আপনি চান ডেটা টাইপ এর মধ্যে ডেটা কিছু জ্ঞান প্রয়োগ করা।

উদাহরণস্বরূপ বলুন আপনার কাছে একটি কলাম রয়েছে যা 20 টি অক্ষরের চেয়ে বেশি হওয়া উচিত নয়। আপনি যদি সেই কলামটিকে VARCHAR (MAX) হিসাবে সংজ্ঞায়িত করেন তবে কিছু দুর্বৃত্ত অ্যাপ্লিকেশন এতে একটি দীর্ঘ স্ট্রিং couldোকাতে পারে এবং আপনি কখনই তা জানতে পারবেন না, বা এটি রোধ করার কোনও উপায় থাকতে পারে।

পরের বার আপনার অ্যাপ্লিকেশনটি সেই স্ট্রিংটি ব্যবহার করে, এই ধারনা অনুযায়ী স্ট্রিংটির দৈর্ঘ্যটি যে ডোমেনটির প্রতিনিধিত্ব করে তার জন্য বিনয়ী এবং যুক্তিসঙ্গত, আপনি একটি অনির্দেশ্য এবং বিভ্রান্তিমূলক ফলাফল উপভোগ করবেন।

— বিল কারভিন
সূত্র
9
আমি এটির সাথে এবং অন্যান্য কিছু মন্তব্যের সাথে একমত, তবে আমি এখনও বজায় রেখেছি যে এটি ব্যবসায়িক স্তরের দায়িত্ব। এটি ডাটাবেস স্তরে পৌঁছানোর সময়, এটি একটি স্যালুট স্নাপ করা উচিত এবং মানটি সংরক্ষণ করা উচিত, এটি যত হাস্যকরভাবেই দীর্ঘ হোক না কেন। আমি মনে করি যে এখানে সত্যিকারের খেলার মধ্যে এটিই হ'ল আমি যখন প্রায় একজন 90% সময় বিবেচনা করি যখন কোনও বিকাশকারী বর্ণচর্চা (255) নির্দিষ্ট করে, তার অভিপ্রায়টি সত্যিই 255 টি অক্ষর নয়, তবে কিছু অনির্ধারিত বিযুক্ত দৈর্ঘ্যের মান। এবং আমার ডিবিতে অযৌক্তিকভাবে বড় মূল্যবোধ এবং অপ্রত্যাশিত ব্যতিক্রমগুলির মধ্যে বাণিজ্য বন্ধ হয়ে যাওয়ার পরে, আমি বড় মানগুলি গ্রহণ করব।
— ক্রিস বি বেরেনস
4
যদি তারা কিছু অজানা দৈর্ঘ্য নির্দেশ করতে ভ্রচার (255) নির্দিষ্ট করে থাকে তবে তারা কী ডিজাইন করছেন তা সঠিকভাবে গবেষণা না করার জন্য তাদের দোষ। সমাধানটি বিকাশকারীদের তাদের কাজ করার জন্য, ডাটাবেসটির জন্য অযৌক্তিক মানগুলির অনুমতি দেওয়ার জন্য নয়।
— টম এইচ
10
লেখকের পক্ষে সহায়ক নয়। আপনি এই প্রশ্নের উত্তর স্পষ্টভাবে বাদ দিয়েছেন to
— usr ডিরেক্টরির
6
@ ক্রিস বি বেরেনস: আমি একমত নই; ডাটাবেসের স্কিমা হয় বিজনেস লজিক অংশ। সারণী, সম্পর্ক, ক্ষেত্র এবং ডেটা ধরণের পছন্দগুলি সমস্ত ব্যবসায়িক যুক্তিযুক্ত - এবং এই ব্যবসায়িক যুক্তির নিয়মগুলি প্রয়োগ করতে আরডিবিএমএস ব্যবহার করা উপযুক্ত। একটি কারণে, এটি খুব বিরল যে কেবলমাত্র একটি অ্যাপ্লিকেশন স্তর ডেটাবেস অ্যাক্সেস করতে পারে; উদাহরণস্বরূপ আপনার কাছে ডেটা আমদানি এবং নিষ্কাশন সরঞ্জাম থাকতে পারে যা মূল ব্যবসায়ের স্তরটিকে বাইপাস করে, যার অর্থ নিয়ম প্রয়োগ করার জন্য আপনার সত্যিকারের ডিবি দরকার।
— ভিন্স বাউডরেন
1
আপনার যদি প্রয়োজন না হয় বা প্রকৃতপক্ষে লম্বা স্ট্রিংগুলি সঞ্চয় করতে চান তবে ডেটা সম্পর্কে জ্ঞান প্রয়োগ করা আরও ভাল। উদাহরণস্বরূপ, যদি কোনও পোস্টকোড ক্ষেত্র সংরক্ষণ করে থাকে তবে আপনি কাউকে কয়েকশো বা কয়েক হাজার অক্ষরে প্রবেশ করতে দিবেন যখন এটি 10 ​​এর সর্বোচ্চ হওয়া উচিত - সর্বোচ্চ আকারটি সমস্ত স্তর, ক্লায়েন্ট, ব্যবসায়িক স্তর এবং ডাটাবেসটি বৈধ করা উচিত। যদি সি # এবং সত্ত্বা ফ্রেমওয়ার্কের মতো কোনও মডেল ফার্স্ট অ্যাপ্রোচ ব্যবহার করা হয়, আপনি মডেলটিতে আপনার ম্যাক্সেসাইজটি সংজ্ঞায়িত করতে পারেন এবং এটি ডাটাবেস, ব্যবসায় যুক্তি এবং ক্লায়েন্টের বৈধতা (jquery বৈধকরণের পছন্দ সহ) প্রয়োগ করতে পারেন। কেবলমাত্র যদি প্রয়োজন হয় তবে কেবল এনভারচর (সর্বাধিক) ব্যবহার করুন
— পিটার কের
21

আমি কিছু নিবন্ধ পরীক্ষা করেছিলাম এবং এর থেকে দরকারী পরীক্ষার স্ক্রিপ্ট পেয়েছি: http://www.sqlservercentral.com/forums/Topic1480639-1292-1.aspx এরপরে এটি এনভিচারার (10) বনাম এনভিচারার (4000) বনাম এনভিচারার (ম্যাক্স) এর মধ্যে তুলনা করুন ) এবং আমি নির্দিষ্ট নম্বর ব্যবহার করার সময় কিন্তু MAX ব্যবহার করার সময় গতির পার্থক্য খুঁজে পাই না। আপনি নিজের দ্বারা পরীক্ষা করতে পারেন। আশা করি এই সাহায্য।

SET NOCOUNT ON;

--===== Test Variable Assignment 1,000,000 times using NVARCHAR(10)
DECLARE @SomeString NVARCHAR(10),
        @StartTime DATETIME;
--=====         
 SELECT @startTime = GETDATE();
 SELECT TOP 1000000
        @SomeString = 'ABC'
   FROM master.sys.all_columns ac1,
        master.sys.all_columns ac2;
 SELECT testTime='10', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO
--===== Test Variable Assignment 1,000,000 times using NVARCHAR(4000)
DECLARE @SomeString NVARCHAR(4000),
        @StartTime DATETIME;
 SELECT @startTime = GETDATE();
 SELECT TOP 1000000
        @SomeString = 'ABC'
   FROM master.sys.all_columns ac1,
        master.sys.all_columns ac2;
 SELECT testTime='4000', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO
--===== Test Variable Assignment 1,000,000 times using NVARCHAR(MAX)
DECLARE @SomeString NVARCHAR(MAX),
        @StartTime DATETIME;
 SELECT @startTime = GETDATE();
 SELECT TOP 1000000
        @SomeString = 'ABC'
   FROM master.sys.all_columns ac1,
        master.sys.all_columns ac2;
 SELECT testTime='MAX', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO
— QMaster
সূত্র
4
এটা আকর্ষণীয়. আমার বাক্সে মনে হচ্ছে MAX এক 4x ধীর।
— stucampbell
4
এসকিউএল সার্ভারে নতুন ফলাফল 2012: 10 4k এর চেয়ে দ্বিগুণ ধীর এবং MAX 4k এর চেয়ে 5.5 গুণ বেশি ধীর।
— cassandrad
1
বেশিরভাগ সময় হ'ল ভার্চর থেকে নব্যারচর (সর্বাধিক) পর্যন্ত অন্তর্নিহিত castালাই। এটি ব্যবহার করে দেখুন: EC @ সোমস্ট্রিং এনভিচারার (ম্যাক্স), ab @ অ্যাবসি এনভিচারার (সর্বাধিক) = এন'এবিসি ', \ @ স্টার্টটাইম ডেটাটাইম; @StartTime = GETDATE () নির্বাচন করুন; শীর্ষ 1000000 নির্বাচন করুন \ @ সোমস্ট্রিং = \ @abc থেকে মাস্টার.সাই.সাল_কলামগুলি AC1, মাস্টার.সিস.ল_কলামগুলি AC2; পরীক্ষার সময় নির্বাচন করুন = 'MAX', সময়কাল = DATEDIFF (এমএস, \ @ স্টার্টটাইম, GETDATE ()); ভেরিয়েবলগুলি পোস্ট করার জন্য এটির আগে inোকাতে হত।
— Kvasi
4
এসএসডি সার্ভার 2014 এসএসডি তে: 150, 156, 716 (10, 4000, MAX)।
— ম্যাক্সিম
2
এই আলোচনায় কিছু আসল সংখ্যা যুক্ত করার জন্য ধন্যবাদ। আমরা প্রায়শই ভুলে যাই যে পরীক্ষার কেস তৈরি করা অন্তর্দৃষ্টি করার দ্রুততম উপায়।
— ডেভিড সি
13

এটিকে অন্য একটি সুরক্ষা স্তর হিসাবে ভাবেন। আপনি বিদেশী কী সম্পর্কগুলি ছাড়াই আপনার টেবিলটি ডিজাইন করতে পারেন - পুরোপুরি বৈধ - এবং ব্যবসায়ের স্তরে সম্পূর্ণরূপে সংশ্লিষ্ট সংস্থাগুলির অস্তিত্ব নিশ্চিত করে। যাইহোক, বিদেশী কীগুলি ভাল নকশার অনুশীলন হিসাবে বিবেচিত হয় কারণ তারা যদি ব্যবসায় স্তরটিতে কিছুটা गडস হয় তবে তারা আরও একটি বাধা স্তর যুক্ত করে। একই ক্ষেত্রের আকার সীমাবদ্ধতার জন্য এবং ভার্চার ম্যাক্স ব্যবহার না করে।

— অ্যালেক্স
সূত্র
8

সর্বাধিক বা পাঠ্য ক্ষেত্রগুলি ব্যবহার না করার একটি কারণ হ'ল আপনি অনলাইন সূচি পুনর্নির্মাণগুলি যেমন অনলাইনে পুনরায় বিল্ড করতে পারবেন না = এমনকি এসকিউএল সার্ভার এন্টারপ্রাইজ সংস্করণ দিয়েও B

— নিক কাভাদিয়াস
সূত্র
1
এই একই বিধিনিষেধটি পাঠ্য ক্ষেত্রের ধরণের জন্য রয়েছে, সুতরাং আপনার এখনও পাঠের পরিবর্তে ভর্চার (ম্যাক্স) ব্যবহার করা উচিত।
— শেভার
এর কারণে আমরা আমাদের ক্লাস্টারড সূচকটি পুনরায় তৈরি করতে পারিনি। যতক্ষণ না আমরা কলামটি তার নিজস্ব টেবিলের মধ্যে বের করতে পারি ততক্ষণ আমাদের অনেক বেশি ডিস্ক স্পেস খরচ করে (আমরা 7 সেকেন্ডের চেয়ে বেশি সময় টেবিলটি লক করতে পারি না)
— স্মিথ
4

একমাত্র সমস্যা আমি দেখা যায় যে আমরা এসকিউএল সার্ভার 2005 আমাদের অ্যাপ্লিকেশন বিকাশ, এবং উদাহরণ হিসেবে বলা যায়, আমরা SQL সার্ভার 2000 শুধুই জেনেছি সমর্থন আছে হার্ড উপায় যে SQL সার্ভার 2000 varchar বা MAX টি বিকল্প পছন্দ করেন না nvarchar।

— mattruma
সূত্র
2
তবে কেন কেবল সর্বনিম্ন সাধারণ ডিনোমিনেটরের উপর বিকাশ হবে না?
— বিনকি
4

খারাপ ধারণা আপনি যখন জানবেন ক্ষেত্রটি একটি নির্দিষ্ট পরিসরে থাকবে - উদাহরণস্বরূপ 5 থেকে 10 অক্ষর। আমার মনে হয় দৈর্ঘ্যটি কী হবে তা আমি যদি নিশ্চিত না থাকতাম তবে আমি কেবলমাত্র সর্বোচ্চ ব্যবহার করতাম। উদাহরণস্বরূপ কোনও টেলিফোন নম্বর কোনও নির্দিষ্ট সংখ্যক অক্ষরের চেয়ে বেশি কখনই হতে পারে না।

আপনি কি সত্যই বলতে পারবেন যে আপনি আপনার টেবিলের প্রতিটি ক্ষেত্রের জন্য আনুমানিক দৈর্ঘ্যের প্রয়োজনীয়তা সম্পর্কে অনিশ্চিত?

যদিও আমি আপনার পয়েন্টটি পেয়েছি- এমন কয়েকটি ক্ষেত্র রয়েছে যা আমি অবশ্যই বর্ণচর (সর্বাধিক) ব্যবহার করে বিবেচনা করব।

মজার বিষয় হল এমএসডিএন ডক্স এটির সংক্ষিপ্ত বিবরণ যোগ করেছে:

কলামের ডাটা এন্ট্রিগুলির আকারগুলি যথেষ্ট পরিমাণে পরিবর্তিত হলে বারচর ব্যবহার করুন। যখন কলামের ডেটা এন্ট্রিগুলির আকারগুলি যথেষ্ট পরিমাণে পৃথক হয়, এবং আকারটি 8,000 বাইটের বেশি হতে পারে তখন বারচর (সর্বোচ্চ) ব্যবহার করুন।

আছে এখানে ইস্যু উপর একটি মজার আলোচনা ।

— RichardOD
সূত্র
2
টেলিফোন নম্বরগুলির মতো জিনিসের জন্য, আমি বার্চারের পরিবর্তে চর ক্ষেত্রটি ব্যবহারের ক্ষেত্রে অনেক বেশি সম্মত হব। যতক্ষণ না আপনি আপনার স্টোরেজে একটি মান বজায় রাখছেন এবং আপনাকে বিভিন্ন দেশ থেকে ফোন নম্বরগুলি নিয়ে চিন্তা করতে হবে না, ফোন নম্বর (কোনও বিন্যাস ছাড়াই 10) বা জিপ কোডের মতো কোনও কিছুর জন্য আপনার কখনই চলক ক্ষেত্রের প্রয়োজন হবে না (5 অথবা আপনি যদি শেষ চারটি সংখ্যা যোগ করেন তবে 9-10) ইত্যাদি
— টিটিএক্সআই
আমি টেলিফোন নম্বরগুলি উল্লেখ করছিলাম যা দৈর্ঘ্যে বিভিন্ন হতে পারে। সম্ভবত আমার উত্তর দেওয়া উচিত। দৈর্ঘ্য স্থিরীকৃত যে কোনও কিছুই আমি একটি চর ক্ষেত্র ব্যবহার করব।
— রিচার্ডড
অথবা সম্ভবত আমি আমার মন্তব্য nchar বা চর মধ্যে বলা উচিত। :-)
— রিচার্ডড
2
একটি টেলিফোন নম্বরের চরিত্রের সংখ্যা বেশিরভাগ ক্ষেত্রে ব্যবসায় প্রয়োজন। যদি আপনার সংখ্যার সাথে আন্তর্জাতিক মানক কোডটি সংরক্ষণ করার প্রয়োজন হয় তবে এটি 10 ​​এরও বেশি হতে পারে বা বিশ্বের কোনও কোনও অংশে একটি ফোন নম্বরের জন্য 10 এর বেশি সংখ্যা থাকতে পারে। আইপিভি 4 এর আইপিভি 6 রূপান্তরটি কল্পনা করুন। কেউই তর্ক করতে পারে না যে ভাল পুরানো আইপিভি 4 দিনে আমাদের 12 টিরও বেশি সংখ্যার প্রয়োজন ছিল। আইপিভি 6 প্রচলিত হয়ে উঠলে এটি ভাল নাও থাকতে পারে। এটি সময়ের সাথে সাথে আবার ব্যবসায়ের নিয়মের পরিবর্তন। যেমনটি বলা হয়েছে, পরিবর্তন কেবলমাত্র আমরা আশা করতে পারি ধ্রুবক জিনিস :)
— পেনসিলট
2
টেলিফোন নম্বর ক্ষেত্রের মধ্যে কতগুলি অক্ষর থাকতে পারে বা কী ধরণের অক্ষর হবে তা আপনি ধরেই নেওয়ার বিষয়ে সতর্ক হন। সিস্টেম যদি না ডায়ালট করার জন্য সেই ডেটা ব্যবহার করে (তবে ক্ষেত্রে আপনাকে ফর্ম্যাট সম্পর্কে কঠোর হতে হবে), তবে ব্যবহারকারী বৈধভাবে সেখানে অপ্রত্যাশিতভাবে দীর্ঘ স্ট্রিং স্থাপন করতে পারেন যেমন "0123 456 78910 এক্সটেনশান 45 এর জন্য অভ্যর্থনা জিজ্ঞাসা করে এবং তারপরে জেমসকে স্থানান্তর করতে"।
— ভিন্স বাউডরেন
4

ডাটাবেসের কাজ হ'ল ডেটা সংরক্ষণ করা যাতে এটি এন্টারপ্রাইজ দ্বারা ব্যবহার করা যায়। ডেটাটিকে দরকারী করে তোলার একটি অংশ তা নিশ্চিত করা যে এটি অর্থবহ। কাউকে তার প্রথম নামের জন্য সীমাহীন সংখ্যক অক্ষর প্রবেশের অনুমতি দেওয়া অর্থবহ ডেটা নিশ্চিত করছে না।

ব্যবসায়ের স্তরে এই প্রতিবন্ধকতা তৈরি করা ভাল ধারণা, তবে এটি নিশ্চিত করে না যে ডাটাবেস অক্ষত থাকবে। ডেটা বিধি লঙ্ঘন না করার গ্যারান্টি দেওয়ার একমাত্র উপায় হ'ল ডেটাবেজে সম্ভব সর্বনিম্ন স্তরে তাদের প্রয়োগ করা।

— টম এইচ
সূত্র
6
আইএমও, ডেটা দৈর্ঘ্যের সীমাবদ্ধতাগুলি নিখুঁতভাবে ব্যবসায়ের নিয়মের উপর নির্ভর করে, যা অ্যাপ্লিকেশন বাড়ার সাথে সাথে সময়ের সাথে সাথে পরিবর্তিত হতে পারে। ব্যবসায়ের যুক্তিতে ব্যবসায়ের নিয়ম পরিবর্তন করা ডিবি স্তরের চেয়ে সহজ। সুতরাং, আমি মনে করি ডিবি নমনীয় যথেষ্ট হওয়া উচিত এবং ব্যবসার নীতি বাঁধা করা উচিত নয় যেমন সর্বোচ্চ প্রথম নাম, যা খুবই জগত সংসার তোমাদের অংশ উপর নির্ভরশীল দৈর্ঘ্য অনুমতি যেখানে আপনার ব্যবহারকারীর জীবন।
— pencilslate
3

একটি সমস্যা হ'ল যদি আপনাকে এসকিউএল সার্ভারের একাধিক সংস্করণ নিয়ে কাজ করতে হয় তবে ম্যাক্স সর্বদা কাজ করবে না। সুতরাং যদি আপনি লিগ্যাসি ডিবি বা অন্য কোনও পরিস্থিতিতে যার সাথে একাধিক সংস্করণ জড়িত থাকে কাজ করে থাকেন তবে আপনি আরও সতর্ক হন।

— TheTXI
সূত্র
আমি মনে করি যে ওপি-র পক্ষ থেকে অব্যক্ত ধারণাটি হ'ল তিনি ২০০++ দৃষ্টান্তের সাথে পুরোপুরি কাজ করছেন এবং তার অ্যাপ্লিকেশনগুলিকে 2000 (বা, এসি, কম) সংস্করণে কাজ করার দরকার নেই। যদিও পুরানো সংস্করণগুলি সমর্থন করার প্রয়োজন আছে তবে আমি সম্পূর্ণরূপে আপনার সাথে একমত হই!
— জন রুডি
জন রুডি: আমি কল্পনা করব এটাই কেস, আমি কেবল জানি যে আমি যখন নিজেকে যাব ভাবছি না তখন আমি নিজেই সেসব প্রতিবন্ধকতাগুলির মধ্যে চলে এসেছি।
— TheTXI
আসলে এটি এসকিউএল সিই 4 এর কারণে আধুনিক স্টাফগুলির সাথে এখনও প্রচলিত সমস্যা যা ম্যাক্স কলামের প্রকারকে সমর্থন করে না তাই আন্তঃব্যবহারযোগ্যতা একটি ঝামেলা।
— জনসি
3

যেমন উপরে উল্লেখ করা হয়েছিল, এটি মূলত স্টোরেজ এবং পারফরম্যান্সের মধ্যে একটি বাণিজ্য। কমপক্ষে বেশিরভাগ ক্ষেত্রেই।

যাইহোক, কমপক্ষে অন্য একটি ফ্যাক্টর রয়েছে যা এন / বার্চার (সর্বাধিক) উপর এন / বার্চার (এন) বেছে নেওয়ার সময় বিবেচনা করা উচিত। ডেটা কি সূচিযুক্ত হতে চলেছে (যেমন, একটি শেষ নাম)? যেহেতু MAX সংজ্ঞাটিকে একটি LOB হিসাবে বিবেচনা করা হয়, তারপরে MAX হিসাবে সংজ্ঞায়িত কোনও কিছুই সূচকের জন্য পাওয়া যায় না। এবং কোনও সূচি ব্যতীত, যেখানে কোনও দফা হিসাবে প্রোকিট হিসাবে ডেটা জড়িত যে কোনও অনুসন্ধানকে একটি পূর্ণ টেবিল স্ক্যানে বাধ্য করা যেতে পারে, এটি ডেটা দেখার জন্য আপনি যে নিকৃষ্টতম পারফরম্যান্স পেতে পারেন এটি is

— হ্যারি কুপার
সূত্র
2

1) এনভিআরচর (সর্বাধিক) বনাম এনভারচর (এন) যেখানে এন ক্ষেত্রের সাথে নির্দিষ্ট একটি নম্বর হিসাবে কাজ করার সময় এসকিউএল সার্ভারকে আরও সংস্থান (বরাদ্দ মেমরি এবং সিপিইউ সময়) ব্যবহার করতে হবে।

২) পারফরম্যান্সের ক্ষেত্রে এর অর্থ কী?

এসকিউএল সার্ভার 2005-এ, আমি 15 টেবিলের নবরচর (সর্বাধিক) কলাম সহ একটি টেবিল থেকে 13,000 সারি ডেটা অনুসন্ধান করেছি। আমি বারবার প্রশ্নের সময়সীমা তৈরি করেছি এবং তারপরে কলামগুলিকে এনভারচর (255) বা তার চেয়ে কম পরিবর্তন করেছি।

অপ্টিমাইজেশনের পূর্ববর্তী ক্যোয়ারীগুলি গড়ে গড়ে 2.0858 সেকেন্ডে হয়। পরিবর্তনের পরে অনুসন্ধানগুলি গড়ে 1.90 সেকেন্ডে ফিরে আসে। এটি ছিল বেসিক সিলেক্ট * ক্যোয়ারীর প্রায় 184 মিলিসেকেন্ডের উন্নতি। এটি একটি 8.8% উন্নতি।

3) আমার ফলাফলগুলি কয়েকটি অন্যান্য নিবন্ধের সাথে একযোগে রয়েছে যা নির্দেশ করে যে পারফরম্যান্সের পার্থক্য ছিল। আপনার ডেটাবেস এবং ক্যোয়ারির উপর নির্ভর করে উন্নতির শতাংশ আলাদা হতে পারে। আপনার যদি খুব বেশি সমসাময়িক ব্যবহারকারী বা খুব বেশি রেকর্ড না থাকে তবে পারফরম্যান্সের পার্থক্যটি আপনার পক্ষে কোনও সমস্যা হবে না। যাইহোক, আরও রেকর্ড এবং সমবর্তী ব্যবহারকারী বৃদ্ধি পাওয়ায় পারফরম্যান্সের পার্থক্য বাড়বে।

— WWC
সূত্র
1

আমার কাছে একটি ইউডিএফ ছিল যা স্ট্রিংগুলি প্যাড করে এবং আউটপুটটি ভারচারে (সর্বোচ্চ) রাখে। এটি কলামটি সামঞ্জস্য করার জন্য উপযুক্ত আকারে toালাইয়ের পরিবর্তে যদি সরাসরি ব্যবহার করা হয়, তবে পারফরম্যান্সটি খুব খারাপ ছিল। আমি স্ট্রিংটিকে আরও ছোট আকারে পুনরায় কাস্ট করতে udf এর সমস্ত কলার উপর নির্ভর না করে একটি বড় নোট সহ udfটিকে একটি স্বেচ্ছাসেদী দৈর্ঘ্যে রেখেছি।

— কেড রক্স
সূত্র
1

লিগ্যাসি সিস্টেম সমর্থন। আপনার যদি এমন কোনও সিস্টেম থাকে যা ডেটা ব্যবহার করে এবং এটি নির্দিষ্ট দৈর্ঘ্যের প্রত্যাশিত হয় তবে দৈর্ঘ্য প্রয়োগের জন্য ডাটাবেসটি ভাল জায়গা। এটি আদর্শ নয় তবে লিগ্যাসি সিস্টেমগুলি কখনও কখনও আদর্শ নয়। = পি

— টনি
সূত্র
1

যদি সারিতে থাকা সমস্ত ডেটা (সমস্ত কলামের জন্য) যুক্তিসঙ্গতভাবে 8000 বা তার চেয়ে কম অক্ষর না নেয় তবে ডেটা স্তরের নকশায় এটি প্রয়োগ করা উচিত।

ডাটাবেস ইঞ্জিন সবকিছুকে ব্লব স্টোরেজ থেকে দূরে রাখতে আরও দক্ষ efficient যত ছোট আপনি একটি সারি আরও ভাল সীমাবদ্ধ করতে পারেন। আপনি আরও বেশি সারি কোনও পৃষ্ঠায় ক্র্যাম করতে পারেন। যখন কম পৃষ্ঠাতে অ্যাক্সেস করতে হবে তখন ডাটাবেসটি আরও ভাল সম্পাদন করে।

— ম্যাট স্প্রেডলি
সূত্র
1

আমার পরীক্ষাগুলি প্রমাণ করেছে যে নির্বাচন করার সময় পার্থক্য রয়েছে।

CREATE TABLE t4000 (a NVARCHAR(4000) NULL);

CREATE TABLE tmax (a NVARCHAR(MAX) NULL);

DECLARE @abc4 NVARCHAR(4000) = N'ABC';

INSERT INTO t4000
SELECT TOP 1000000 @abc4
    FROM
    master.sys.all_columns ac1,
    master.sys.all_columns ac2;

DECLARE @abc NVARCHAR(MAX) = N'ABC';

INSERT INTO tmax
SELECT TOP 1000000 @abc
    FROM
    master.sys.all_columns ac1,
    master.sys.all_columns ac2;

SET STATISTICS TIME ON;
SET STATISTICS IO ON;

SELECT * FROM dbo.t4000;
SELECT * FROM dbo.tmax;
— Kvasi
সূত্র
0

আকর্ষণীয় লিঙ্ক: আপনি যখন টেক্সট ব্যবহার করতে পারেন তখন কেন একটি ভোচারার ব্যবহার করবেন?

এটি পোস্টগ্রাইএসকিউএল এবং মাইএসকিউএল সম্পর্কিত, সুতরাং পারফরম্যান্স বিশ্লেষণ আলাদা, তবে "এক্সপ্লিটাইটিস" এর যুক্তিটি এখনও ধরে রেখেছে: কেন নিজেকে সামান্য সময়ের সাথে সামঞ্জস্যপূর্ণ এমন কিছু সম্পর্কে সর্বদা উদ্বিগ্ন হতে বাধ্য করতে হবে? যদি আপনি কোনও ভেরিয়েবলের কোনও ইমেল ঠিকানা সংরক্ষণ করেন তবে আপনি 'স্ট্রিং' নয় 'স্ট্রিং সীমাবদ্ধ 80 অক্ষরে' ব্যবহার করবেন d

— orip
সূত্র
1
এটি যুক্তিযুক্ত যে আপনার ব্যক্তির বয়স কোনও নেতিবাচক সংখ্যা নয় তা নিশ্চিত করার জন্য আপনার চেক বাধা থাকা উচিত নয় ing
— জোনাথন অ্যালেন
আমি ডেটা নির্ভুলতা এবং পারফরম্যান্স অপ্টিমাইজেশনের মধ্যে পার্থক্য দেখছি।
— orip
0

আমি দেখতে পাচ্ছি প্রধান অসুবিধাটি হ'ল এটি আপনার বলা আছে:

কোনটি আপনাকে ইউআইয়ের জন্য প্রয়োজনীয় ডেটা সম্পর্কে সর্বাধিক তথ্য দেয়?

এই

            CREATE TABLE [dbo].[BusData](
                [ID] [int] IDENTITY(1,1) NOT NULL,
                [RecordId] [nvarchar](MAX) NULL,
                [CompanyName] [nvarchar](MAX) NOT NULL,
                [FirstName] [nvarchar](MAX) NOT NULL,
                [LastName] [nvarchar](MAX) NOT NULL,
                [ADDRESS] [nvarchar](MAX) NOT NULL,
                [CITY] [nvarchar](MAX) NOT NULL,
                [County] [nvarchar](MAX) NOT NULL,
                [STATE] [nvarchar](MAX) NOT NULL,
                [ZIP] [nvarchar](MAX) NOT NULL,
                [PHONE] [nvarchar](MAX) NOT NULL,
                [COUNTRY] [nvarchar](MAX) NOT NULL,
                [NPA] [nvarchar](MAX) NULL,
                [NXX] [nvarchar](MAX) NULL,
                [XXXX] [nvarchar](MAX) NULL,
                [CurrentRecord] [nvarchar](MAX) NULL,
                [TotalCount] [nvarchar](MAX) NULL,
                [Status] [int] NOT NULL,
                [ChangeDate] [datetime] NOT NULL
            ) ON [PRIMARY]

অথবা এটা?

            CREATE TABLE [dbo].[BusData](
                [ID] [int] IDENTITY(1,1) NOT NULL,
                [RecordId] [nvarchar](50) NULL,
                [CompanyName] [nvarchar](50) NOT NULL,
                [FirstName] [nvarchar](50) NOT NULL,
                [LastName] [nvarchar](50) NOT NULL,
                [ADDRESS] [nvarchar](50) NOT NULL,
                [CITY] [nvarchar](50) NOT NULL,
                [County] [nvarchar](50) NOT NULL,
                [STATE] [nvarchar](2) NOT NULL,
                [ZIP] [nvarchar](16) NOT NULL,
                [PHONE] [nvarchar](18) NOT NULL,
                [COUNTRY] [nvarchar](50) NOT NULL,
                [NPA] [nvarchar](3) NULL,
                [NXX] [nvarchar](3) NULL,
                [XXXX] [nvarchar](4) NULL,
                [CurrentRecord] [nvarchar](50) NULL,
                [TotalCount] [nvarchar](50) NULL,
                [Status] [int] NOT NULL,
                [ChangeDate] [datetime] NOT NULL
            ) ON [PRIMARY]
— কার্লোস মার্টিনি
সূত্র
3
আমি ব্যবসায়ের যুক্তি আমাকে পছন্দ করে বলতে চাই যে কোনও তথ্যের জন্য একটি ডাটাবেস টেবিলের উপর নির্ভর না করে কোনও কোম্পানির নাম সর্বাধিক 50 টি অক্ষর হতে পারে।
— খান
আমি জেফের সাথে একমত আপনার ব্যবসায়িক বিধিগুলি সংজ্ঞায়নের জন্য দৃ the়তা সঞ্চয়টি সঠিক জায়গা বলে আমি মনে করি না। এবং একটি স্তরযুক্ত আর্কিটেকচারে আপনার ইউআই এমনকি অধ্যবসায় স্তর সম্পর্কে জানতে পারে না।
— স্তকম্পবেল
অবশ্যই আপনি কোনও মান ব্যবহার করছেন যা নির্দিষ্ট আকারের জন্য সীমাবদ্ধ, উদাহরণস্বরূপ দেশের জন্য আইএসও কোড।
— বেন
2
এটি একটি টেবিল ডিএফ সঙ্গে কি আছে? আপনার এখনও ব্যবসায়িক যুক্তি থাকতে পারে। আমি মনে করি যে কোনও টেবিলটি কীভাবে ডিজাইন করা হয়েছে তার সাথে সম্পর্কিতভাবে আপনার বক্তব্য কোনও অর্থবহ নয়। আপনি যদি এখনও আপনার ব্যবসায়ের স্তরে কোনও ধরণের সংজ্ঞা ডিজাইন করতে চান তবে তা হয়ে উঠুন। যদিও এটি আরও অর্থবহ করে তুলবে, তা ব্যবসায়ের স্তরে যে কোনও উপায়ে একটি সঞ্চিত ব্যবহার করা হয়; একটি টেবিল ডিফ না ??
— কার্লোস মার্টিনি
1
এটি অপ্রিয় বলে মনে হচ্ছে তবে আমি কার্লোসের সাথে একমত, যদি ডিবি সর্বোচ্চ আকার নির্ধারণ করে তবে আপনি এটির উপরে যে স্তরগুলি তৈরি করেন তার উপরে আপনি স্বাচ্ছন্দ্য বোধ করতে পারেন যা আপনার মোকাবেলা করতে পারে। আপনার ডেটাবেজে একাধিক সিস্টেম লেখা থাকলে এটি বিশেষত গুরুত্বপূর্ণ।
— টিম আবেল
0

এর একটি অসুবিধা হ'ল আপনি একটি অনির্দেশ্য পরিবর্তনশীলকে ঘিরে ডিজাইন করবেন এবং আপনি সম্ভবত অভ্যন্তরীণ এসকিউএল সার্ভারের ডেটা স্ট্রাকচারের সুবিধা গ্রহণের পরিবর্তে ক্রমান্বয়ে সারি (গুলি), পৃষ্ঠা (গুলি) এবং এক্সটেন্ডেন্ট (গুলি) দ্বারা গঠিত এটিকে উপেক্ষা করবেন।

যা আমাকে সিতে ডেটা স্ট্রাকচার প্রান্তিককরণ সম্পর্কে চিন্তাভাবনা করে এবং এ্যালাইনমেন্ট সম্পর্কে সচেতন হওয়া সাধারণত একটি ভাল জিনিস (টিএম) হিসাবে বিবেচিত হয়। একই ধারণা, বিভিন্ন প্রসঙ্গে।

পৃষ্ঠাগুলি এবং এক্সেটেন্টগুলির জন্য এমএসডিএন পৃষ্ঠা

সারি-ওভারফ্লো ডেটার জন্য এমএসডিএন পৃষ্ঠা

— tsundoku
সূত্র
0

প্রথমে আমি এই সম্পর্কে চিন্তা, কিন্তু তারপর আবার চিন্তা। পারফরম্যান্সের প্রভাব রয়েছে, তবে সমানভাবে ক্ষেত্রগুলি আসলে কি আকারের তা ধারণা রাখতে ডকুমেন্টেশনের একটি রূপ হিসাবে কাজ করে। এবং এটি কার্যকর করে যখন ডেটাবেস বৃহত্তর বাস্তুতন্ত্রে বসে। আমার মতে মূলটি অনুমতিযোগ্য তবে কেবল কারণের মধ্যে থাকা উচিত।

ঠিক আছে, কেবল ব্যবসা এবং ডেটা স্তর যুক্তির ইস্যুতে আমার অনুভূতি এখানে। এটি নির্ভর করে, যদি আপনার ডিবি ব্যবসায়ের যুক্তি ভাগ করে এমন সিস্টেমগুলির মধ্যে একটি ভাগ করা সংস্থান হয় তবে অবশ্যই এই জাতীয় যুক্তি প্রয়োগের প্রাকৃতিক জায়গা বলে মনে হয়, তবে এটি করার সর্বোত্তম উপায় নয়, সেরা উপায়টি একটি এপিআই সরবরাহ করা, এটি অনুমতি দেয় মিথস্ক্রিয়াটি যাচাই করা হবে এবং ব্যবসার যুক্তি যেখানে এটি রয়েছে তা রাখে, এটি সিস্টেমগুলিকে ডিকপলড রাখে, এটি আপনার স্তরগুলি ডিকোপলড সিস্টেমের মধ্যে রাখে। তবে যদি আপনার ডাটাবেসটি কেবলমাত্র একটি অ্যাপ্লিকেশন সরবরাহ করছে বলে মনে করা হয়, তবে ভেবে চিন্তায় অ্যাগ্রিল পেতে দিন, এখন কী সত্য? এখন জন্য ডিজাইন। যদি এবং যখন এই ধরণের অ্যাক্সেসের প্রয়োজন হয়, তখন সেই ডেটাতে একটি API সরবরাহ করুন।

স্পষ্টতই, এটি কেবল আদর্শ, যদি আপনি একটি বিদ্যমান সিস্টেমের সাথে কাজ করছেন তবে সম্ভাব্যতা হ'ল কমপক্ষে স্বল্পমেয়াদে আপনাকে এটি ভিন্নভাবে করার দরকার হবে।

— স্টিফেন হিপ্প
সূত্র
-1

এটি পারফরম্যান্স সমস্যার কারণ হতে পারে, যদিও এটি আপনার ডাটাবেস ছোট হলে এটি কখনও আসল সমস্যা সৃষ্টি করতে পারে না। প্রতিটি রেকর্ড হার্ড ড্রাইভে আরও স্থান গ্রহণ করবে এবং আপনি যদি একবারে অনেকগুলি রেকর্ড অনুসন্ধান করে থাকেন তবে ডাটাবেসটিকে ডিস্কের আরও সেক্টর পড়তে হবে। উদাহরণস্বরূপ, একটি ছোট রেকর্ডটি একটি সেক্টরের সাথে 50 টি ফিট হতে পারে এবং একটি বৃহত রেকর্ড ৫ টি ফিট হতে পারে You আপনাকে বড় রেকর্ডটি ব্যবহার করে ডিস্ক থেকে 10 গুণ বেশি তথ্য পড়তে হবে।

— ড্যান গোল্ডস্টেইন
সূত্র
5
-1। একটি nvarchar(max)কলামে সঞ্চিত দৈর্ঘ্যের 100 টি স্ট্রিং কলামে থাকলে ডিস্কের বেশি জায়গা নেয় না nvarchar(100)।
— মার্টিন স্মিথ
আপনি যা বর্ণনা করছেন তা সঠিক যদি সঞ্চিত ডেটার আকার বেশি হয় তবে এই প্রশ্নটি ডেটা টাইপের পারফরম্যান্সের প্রভাব বা অন্যান্য বিবেচ্য বিষয়গুলি সম্পর্কে কিনা।
-2

এটি স্ক্রিন ডিজাইনটিকে আরও শক্ত করে তুলবে কারণ আপনার নিয়ন্ত্রণগুলি কত প্রশস্ত হওয়া উচিত তা আপনি আর অনুমান করতে পারবেন না able

— pappes
সূত্র
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.