এসকিউএল সার্ভার ভর্চার কলাম প্রস্থ


14

ওয়েবের চারপাশে অনুসন্ধান করে, আমি অত্যধিক-প্রশস্ত ভোচারার কলামগুলি নির্দিষ্ট করে যখন উদাহরণস্বরূপ (255) যখন ভর্চার (30) সম্ভবত করবে তখন কোনও পারফরম্যান্সের প্রভাব আছে কিনা সে সম্পর্কে আমি বিরোধী পরামর্শ পেয়েছি।

আমি ক্রমাগতভাবে চুক্তিটি দেখছি যে পুরো সারিটি 8060 বাইট ছাড়িয়ে গেলে একটি পারফরম্যান্স হিট হয়। তা ছাড়া আমি ভিন্নমত পোষণ করি।

দাবি কি সত্য The default is SET ANSI PADDING ON = potential for lots of trailing spaces? যতক্ষণ না মোট সারির প্রস্থ 8060 এরও কম থাকে, ওভার সাইজিং ভর্চার কলামগুলিতে কি কোনও বাস্তব পারফরম্যান্স উদ্বেগ রয়েছে?

প্রমাণ যে কলাম প্রস্থ গুরুত্বপূর্ণ


The same goes for CHAR and VARCHAR data types. Don’t specify more characters in character columns that you need.

http://www.sql-server-performance.com/2007/datatypes/


  • Length is a constraint on the data (like CHECK, FK, NULL etc)
  • Performance when the row exceeds 8060 bytes
  • Can not have unique constraint or index (key column width must be < 900)
  • The default is SET ANSI PADDING ON = potential for lots of trailing spaces

ভারচার সেট করার পরিণতিগুলি কী (8000)?


প্রমাণ যে কলাম প্রস্থ কোন ব্যাপার না


If you're talking about varchar and nvarchar then no, there is no penalty for allowing a higher field length.

/programming/7025996/overstating-field-size-in-database-design


The varchar datatype, by contrast, consumes only the amount of actual space used plus 2 bytes for overhead

http://sqlfool.com/content/PerformanceConsiderationsOfDataTypes.pdf


উত্তর:


7

প্রশ্নটি আরও ভালভাবে বলা যেতে পারে:

"ভেরিয়েবল-দৈর্ঘ্যের কলামটির সর্বোচ্চ দৈর্ঘ্য অতিরিক্ত-নির্দিষ্ট করে কী লাভ?"

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

ইন কিছু ক্ষেত্রে , যেখানে একটি কলাম গড় দৈর্ঘ্য উল্লেখযোগ্যভাবে বেশী 50% যখন সাজানোর / হ্যাশ মেমরির অনুদান গণক SQL সার্ভার দ্বারা অধিকৃত হয়, তাহলে আপনি ওভার উল্লেখ সর্বাধিক দৈর্ঘ্য দ্বারা একটি কর্মক্ষমতা বৃদ্ধি দেখতে পারেন। এটি একটি সন্দেহজনক কাজ এবং সম্ভবত বেস কলাম সংজ্ঞা পরিবর্তনের পরিবর্তে কেবল একটি স্পষ্ট CASTবা CONVERT(মন্তব্য সহ) প্রয়োগ করা উচিত । কখনও কখনও, যে কোনওভাবেই পুরো সারিগুলির পরিবর্তে কীগুলি বাছাই করার জন্য ক্যোয়ারীটি পুনরায় লেখা ভাল ।

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

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


-3

যেমন আপনি সূচিত করেছেন, যতক্ষণ না সারিটির আকার 8060 (বা সর্বাধিক নির্ধারিত যাই হোক না কেন) অতিক্রম না করে, VARCHAR (30) বা ভারচার (255) বা তার চেয়ে বড় ব্যবহারের ক্ষেত্রে পারফরম্যান্সের কোনও পার্থক্য নেই। সংযুক্ত নিবন্ধ থেকে CHAR থেকে VARCHAR তুলনা আসলে প্রাসঙ্গিক নয়। যদিও আমি সম্মত হই যে আপনার নিজের প্রয়োজনের তুলনায় আপনার আরও বেশি স্থান নির্দিষ্ট করা উচিত নয়, অনেক ক্ষেত্রে আপনি জানেন না যে আসলে আপনার কতটা জায়গা প্রয়োজন হবে। সুতরাং ভর্চার স্থানের সাথে উদার হন - আমি দৃ pretty়ভাবে নিশ্চিত যে ক্ষেত্রের আকার বাড়ানোর জন্য একটি টেবিল পুনর্নির্মাণের প্রয়োজন, যখন হ্রাস হ্রাস করা একটি সহজ বিকল্প টেবিল বিবৃতি।


6
পরিবর্তনশীল দৈর্ঘ্যের কলামগুলির আকার বাড়ানো একটি সাধারণ মেটাডেটা পরিবর্তন ( maxথেকে বাড়ানো বাদে non max)। এটি বিপরীত দিক যা উচ্চ ওভারহেড রয়েছে।
মার্টিন স্মিথ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.