আমি ইতিমধ্যে এখানে আরও একটি উত্তর যুক্ত করতে সংকোচ করছি কারণ ইতিমধ্যে বেশ কয়েকটি রয়েছে, তবে কয়েকটি পয়েন্ট করা দরকার যা হয় হয় নি বা পরিষ্কারভাবে তৈরি করা হয়নি।
প্রথম: সর্বদা ব্যবহার করবেন নাNVARCHAR । এটি একটি অত্যন্ত বিপজ্জনক এবং প্রায়শই ব্যয়বহুল / দৃষ্টিভঙ্গি / এবং " কার্সারগুলি কখনই ব্যবহার করবেন না " বলা আরও ভাল নয় কারণ এগুলি কখনও কখনও কোনও নির্দিষ্ট সমস্যা সমাধানের সবচেয়ে কার্যকর মাধ্যম এবং WHILEলুপ করার সাধারণ কাজটি প্রায়শই একটি সঠিকভাবে সম্পন্ন কার্সারের চেয়ে ধীর হয়ে যায় ।
"সর্বদাই" শব্দটি ব্যবহার করা উচিত কেবল তখনই যখন "পরিস্থিতিটি সর্বোত্তম হয় তার জন্য পরামর্শ দিন"। অনুমোদিত যে প্রায়শই কঠিন, বিশেষত যখন উন্নয়নের সময় স্বল্পমেয়াদী লাভের ভারসাম্য বজায় রাখার চেষ্টা করা হয় (পরিচালক: "আমাদের এই বৈশিষ্ট্যটি দরকার - যা আপনি এখন অবধি জানেন না - এক সপ্তাহ আগে!") দীর্ঘ সহ -কালীন রক্ষণাবেক্ষণ ব্যয় (ম্যানেজার যিনি 3 সপ্তাহের স্প্রিন্টে 3 মাসের একটি প্রকল্প শেষ করতে টিমকে চাপ দিয়েছিলেন: "আমাদের এই পারফরম্যান্সের সমস্যা কেন? আমরা সম্ভবত এক্স কীভাবে করতে পারি যার কোনও নমনীয়তা নেই? আমরা সামর্থ্য না পারি) এটি ঠিক করার জন্য দুটি বা একটি স্প্রিন্ট a এক সপ্তাহের মধ্যে আমরা কী করতে পারি যাতে আমরা আমাদের অগ্রাধিকার আইটেমগুলিতে ফিরে যেতে পারি? এবং আমাদের অবশ্যই ডিজাইনে আরও বেশি সময় ব্যয় করা দরকার যাতে এটি না ঘটে! ")।
দ্বিতীয়: @ জিবিএন এর উত্তরটি যখন পথটি 100% পরিষ্কার নয় তখন নির্দিষ্ট ডেটা মডেলিংয়ের সিদ্ধান্ত নেওয়ার সময় বিবেচনা করার জন্য কয়েকটি খুব গুরুত্বপূর্ণ পয়েন্টগুলিকে স্পর্শ করে। তবে বিবেচনা করার মতো আরও অনেক বিষয় রয়েছে:
- লেনদেনের লগ ফাইলের আকার
- প্রতিলিপি তৈরি করতে সময় লাগে (যদি প্রতিলিপি ব্যবহার করা হয়)
- ETL এ সময় লাগে (যদি ETLing হয়)
- কোনও রিমোট সিস্টেমে লগগুলি চালিত করতে এবং পুনরুদ্ধার করতে সময় লাগে (যদি লগ শিপিং ব্যবহার করা হয়)
- ব্যাকআপ আকার
- ব্যাকআপটি সম্পূর্ণ করতে সময় লাগে
- পুনরুদ্ধার করতে সময় লাগবে (এটি কোনও দিন গুরুত্বপূর্ণ হতে পারে ;-)
- টেম্পডিবির জন্য আকার প্রয়োজন
- ট্রিগারগুলির কার্য সম্পাদন (tempোকানো এবং মুছে ফেলা টেবিলগুলি যা টেম্পিডবিতে সঞ্চিত থাকে)
- সারি সংস্করণের সংস্করণ (যদি SNAPSHOT বিচ্ছিন্নতা ব্যবহার করা হয়, যেহেতু সংস্করণ স্টোরটি টেম্পডবিতে রয়েছে)
- নতুন ডিস্কের স্থান পাওয়ার ক্ষমতা যখন সিএফও বলে যে তারা গত বছর সানটিতে মাত্র ১ মিলিয়ন ডলার ব্যয় করেছে এবং তাই তারা অতিরিক্ত স্টোরেজের জন্য আরও another 250k অনুমোদন করবে না
- INSERT এবং আপডেট আপডেট করতে সময় লাগে
- সূচি রক্ষণাবেক্ষণ করতে সময় লাগে
- ইত্যাদি, ইত্যাদি
নষ্ট স্থানটি পুরো সিস্টেমে একটি বিশাল ক্যাসকেড প্রভাব ফেলে। আমি এই বিষয়ে সুস্পষ্ট বিবরণ নিয়ে একটি নিবন্ধ লিখেছিলাম: ডিস্ক ইজ সস্তা! Orly? (নিখরচায় নিবন্ধকরণ প্রয়োজন; দুঃখিত আমি সেই নীতিটি নিয়ন্ত্রণ করি না)।
তৃতীয়: যদিও কিছু উত্তরগুলি ভুলভাবে "এটি একটি ছোট অ্যাপ্লিকেশন" দিকটির দিকে ফোকাস করছে এবং কিছু সঠিকভাবে "উপযুক্ত যা ব্যবহার করতে" পরামর্শ দিচ্ছে, উত্তরগুলির মধ্যে কোনওটিই ওপিকে সত্যিকারের দিকনির্দেশনা সরবরাহ করতে পারেননি প্রশ্নে বর্ণিত একটি গুরুত্বপূর্ণ বিবরণ এটি তাদের স্কুলের জন্য একটি ওয়েব পৃষ্ঠা web গ্রেট! সুতরাং আমরা পরামর্শ দিতে পারি যে:
- শিক্ষার্থীর এবং / অথবা অনুষদ নামের জন্য ক্ষেত্রসমূহ উচিত সম্ভবত হতে
NVARCHAR, যেহেতু সময়ের সাথে, এটি শুধুমাত্র সম্ভাবনা বেশি যে অন্যান্য সংস্কৃতির নাম সে জায়গায় দেখানো হবে হচ্ছে।
- তবে রাস্তার ঠিকানা এবং শহরের নাম? অ্যাপ্লিকেশনটির উদ্দেশ্য বর্ণিত হয়নি (এটি সহায়ক হতে পারে) তবে ঠিকানার কোনও নির্দিষ্ট ভৌগলিক অঞ্চলে (যেমন একক ভাষা / সংস্কৃতি) এর সাথে সম্পর্কিত, তবে ঠিকানা রেকর্ডগুলি ধরে নিলে
VARCHARযথাযথ কোড পৃষ্ঠাটি ব্যবহার করুন (যা ক্ষেত্রের কোলেশন থেকে নির্ধারিত হয়)।
- যদি রাজ্য এবং / অথবা দেশের ISO কোডগুলি (স্টোর করার কোন প্রয়োজন সংরক্ষণকারী
INT/ TINYINTযেহেতু ISO কোডগুলি ঠিক করা হয়েছে দৈর্ঘ্য, মানব পাঠযোগ্য, এবং ভাল, মানক :) ব্যবহার CHAR(2)দুই অক্ষর কোডগুলি এবং CHAR(3)যদি 3 অক্ষর কোড ব্যবহার। এবং যেমন একটি বাইনারি কলেশন ব্যবহার বিবেচনা করুন Latin1_General_100_BIN2।
- যদি পোষ্টাল কোডগুলি (যেমন পিন কোডগুলি) সংরক্ষণ
VARCHARকরে থাকে তবে এটি এজেডের বাইরে কোনও অক্ষর কখনও ব্যবহার না করা আন্তর্জাতিক মানের এটি ব্যবহার করুন। এবং হ্যাঁ, এখনও VARCHARকেবল ইউএস জিপ কোডগুলি সংরক্ষণ করে এবং INT না থাকলেও ব্যবহার করুন যেহেতু জিপ কোডগুলি সংখ্যা নয়, সেগুলি স্ট্রিং রয়েছে এবং তাদের মধ্যে কিছুগুলির একটি শীর্ষস্থানীয় "0" রয়েছে। এবং যেমন একটি বাইনারি কলেশন ব্যবহার বিবেচনা করুন Latin1_General_100_BIN2।
- যদি ইমেল ঠিকানা এবং / অথবা ইউআরএল সংরক্ষণ করে তবে
NVARCHARসেগুলির দুটিই এখন ইউনিকোড অক্ষর ধারণ করতে পারে।
- ইত্যাদি
চতুর্থ: এখন যে NVARCHARতথ্য আপনার প্রয়োজনের তুলনায় দ্বিগুণ জায়গা গ্রহণ করেছে যা VARCHAR"" ফিট করে সুন্দরভাবে "=" তে পরিণত হয় না? ") এবং কোনওভাবে, যাদু দ্বারা, অ্যাপ্লিকেশনটি বৃদ্ধি পেয়েছে এবং এখন এই ক্ষেত্রগুলির মধ্যে কমপক্ষে একটিতে লক্ষ লক্ষ রেকর্ড রয়েছে যেখানে বেশিরভাগ সারিগুলি স্ট্যান্ডার্ড ASCII হয় তবে কয়েকটিতে ইউনিকোড অক্ষর থাকে যাতে আপনাকে ধরে রাখতে হয় NVARCHAR, নিম্নলিখিতটি বিবেচনা করুন:
আপনি যদি এসকিউএল সার্ভার ২০০৮ - ২০১T আরটিএম ব্যবহার করে থাকেন এবং এন্টারপ্রাইজ সংস্করণে রয়েছেন বা এসকিউএল সার্ভার 2016 এসপি 1 (যা সমস্ত সংস্করণে ডেটা সংক্ষেপণ উপলভ্য করেছে) বা আরও নতুন ব্যবহার করে থাকে তবে আপনি ডেটা সংক্ষেপণ সক্ষম করতে পারেন । ডেটা সংক্ষেপণ ( NCHARএবং "সর্বদা" হবে না) ইউনিকোড ডেটা এবং NVARCHARক্ষেত্রগুলিকে সংকুচিত করতে পারে । নির্ধারণকারী কারণগুলি হ'ল:
NCHAR(1 - 4000)এবং NVARCHAR(1 - 4000)ব্যবহার ইউনিকোড জন্য আদর্শ কম্প্রেশন স্কিম , কিন্তু শুধুমাত্র 2008 R2 হলো, এবং শুধুমাত্র সারির ডেটার জন্য SQL সার্ভার শুরু না ওভারফ্লো! এটি নিয়মিত ROW / PAGE সংক্ষেপণ অ্যালগরিদমের চেয়ে ভাল বলে মনে হয়।NVARCHAR(MAX)এবং XML(এবং আমিও অনুমান করি এবং VARBINARY(MAX), TEXTএবং NTEXT) যে তথ্য সারি (LOB বা ওভারফ্লু পৃষ্ঠায় সারি বন্ধ নয়) কমপক্ষে পৃষ্ঠা সংকুচিত হতে পারে, তবে ROW সংকুচিত হতে পারে না । অবশ্যই, পৃষ্ঠাগুলি সংক্ষেপণ ইন-সারি মানের আকারের উপর নির্ভর করে: আমি ভিচারার (ম্যাক্স) দিয়ে পরীক্ষা করেছি এবং দেখেছি যে 6000 অক্ষর / বাইট সারিগুলি সংকোচিত করবে না, তবে 4000 অক্ষর / বাইট সারিগুলি করেছে।- যে কোনও অফ রো অফ ডেটা, এলওবি বা ওভারলও = আপনার জন্য কোনও সংকোচনের দরকার নেই!
যদি এসকিউএল সার্ভার 2005 বা 2008 - 2016 আরটিএম ব্যবহার করে এবং এন্টারপ্রাইজ সংস্করণে না হয় তবে আপনার দুটি ক্ষেত্র থাকতে পারে: একটি VARCHARএবং একটি NVARCHAR। উদাহরণস্বরূপ, ধরা যাক আপনি ইউআরএলগুলি সংরক্ষণ করছেন যা বেশিরভাগই সমস্ত বেস ASCII অক্ষর (মান 0 - 127) এবং তাই এর মধ্যে ফিট হয় VARCHARতবে কখনও কখনও ইউনিকোড অক্ষর থাকে। আপনার স্কিমাতে নিম্নলিখিত 3 টি ক্ষেত্র অন্তর্ভুক্ত থাকতে পারে:
...
URLa VARCHAR(2048) NULL,
URLu NVARCHAR(2048) NULL,
URL AS (ISNULL(CONVERT(NVARCHAR([URLa])), [URLu])),
CONSTRAINT [CK_TableName_OneUrlMax] CHECK (
([URLa] IS NOT NULL OR [URLu] IS NOT NULL)
AND ([URLa] IS NULL OR [URLu] IS NULL))
);
এই মডেলটিতে আপনি কেবল[URL] গণিত কলামটি থেকে নির্বাচন করুন । সন্নিবেশ এবং আপডেট করার জন্য, আপনি কোন ক্ষেত্রটি ব্যবহার করবেন তা দেখে তা নির্ধারণ করে আগত মানটি পরিবর্তিত হয় কিনা, যা NVARCHARটাইপের হতে হবে :
INSERT INTO TableName (..., URLa, URLu)
VALUES (...,
IIF (CONVERT(VARCHAR(2048), @URL) = @URL, @URL, NULL),
IIF (CONVERT(VARCHAR(2048), @URL) <> @URL, NULL, @URL)
);
আপনি আগত মানগুলিকে GZIP করতে পারেন VARBINARY(MAX)এবং তারপরে বেরিয়ে যাওয়ার পথে আনজিপ করতে পারেন:
- এসকিউএল সার্ভার 2005 - 2014 এর জন্য: আপনি এসকিউএলসিএলআর ব্যবহার করতে পারেন। এসকিউএল # (আমি লিখেছি এমন একটি এসকিউএলসিআরআর পাঠাগার) নিখরচায় সংস্করণে Util_GZip এবং Util_GUnzip সহ আসে
- এসকিউএল সার্ভার ২০১ 2016 এবং আরও নতুনর জন্য: আপনি বিল্ট-ইন
COMPRESSএবং DECOMPRESSফাংশনগুলি ব্যবহার করতে পারেন , এটি জি জিপও।
যদি এসকিউএল সার্ভার 2017 বা আরও নতুন ব্যবহার করে থাকে তবে আপনি টেবিলটিকে ক্লাস্টারড কলামস্টোর সূচক তৈরি করতে পারেন।
যদিও এটি এখনও কার্যকর ব্যবহারযোগ্য বিকল্প নয়, এসকিউএল সার্ভার 2019 ইউটিএফ -8 এর জন্য VARCHAR/ CHARডেটাটাইপগুলিতে স্থানীয় সমর্থন প্রবর্তন করে । এটি ব্যবহার করার জন্য এটির সাথে বর্তমানে এটিতে প্রচুর বাগ রয়েছে, তবে সেগুলি স্থির করা থাকলে, কিছু পরিস্থিতিতে এটি একটি বিকল্প । এই নতুন বৈশিষ্ট্যের বিশদ বিশ্লেষণের জন্য দয়া করে আমার পোস্টটি " এসকিউএল সার্ভার 2019-এ নেটিভ ইউটিএফ -8 সমর্থন: ত্রাণকর্তা বা ভুয়া নবী? " দেখুন।