ما حجم لاختيار عمود (ن) varchar؟

Question

في مناقشة ساخنة قليلا على TDWTF نشأ سؤال حول حجم أعمدة Varchar في DB.

على سبيل المثال، خذ حقل يحتوي على اسم الشخص (مجرد اسم، لا لقب). من السهل جدا أن نرى أنها لن تكون طويلة جدا. معظم الناس لديهم أسماء بأقل من 10 أحرف، وعدد قليل من هم أكثر من 20. إذا كنت ستجعل العمود الخاص بك، فقل، varchar (50)، بالتأكيد ستحمل جميع الأسماء التي ستواجهها من أي وقت مضى.

ومع ذلك بالنسبة لمعظم DBMS، فإنه لا يوجد فرق في الحجم أو السرعة سواء قمت بإجراء varchar (50) أو varchar (255).

فلماذا يحاول الناس جعل أعمدةهم صغيرة قدر الإمكان؟ أنا أفهم أنه في بعض الحالة قد ترغب في الواقع في وضع حد على طول السلسلة، ولكن في الغالب ليس كذلك. وسيكون هامش أوسع مفيدا إلا إذا كان هناك حالة نادرة لشخص لديه اسم طويل للغاية.

---

وأضاف: يريد الناس مراجع إلى البيان حول "لا فرق في الحجم أو السرعة". نعم. ها هم:

ل mssql: http://msdn.microsoft.com/en-us/library/ms176089.aspx.

حجم التخزين هو الطول الفعلي للبيانات التي تم إدخالها + 2 بايت.

ل mysql: http://dev.mysql.com/doc/refman/5.1/en/storage-requirements.html.

L + 1 BYTES إذا كانت قيم الأعمدة تتطلب 0 - 255 بايت، L + 2 BYTES إذا كانت القيم قد تتطلب أكثر من 255 بايت

لا يمكنني العثور على وثائق Oracle ولم أعمل مع DBMS الأخرى. لكن ليس لدي أي سبب للاعتقاد بأنه مختلف هناك.

Answer 1

لا أستطيع التحدث فقط عن أوراكل. يتناول Varchar2 (50) و varchar2 (255) نفس القدر من المساحة والأداء بشكل متطابق، إذا أدخلت القيمة "سميث".

ومع ذلك، فإن السبب وراء عدم وجود فكرة جيدة عن إعلان جميع الأعمدة النصية الخاصة بك كما varchar2 (4000) هو أن طول العمود هو، فعليا، قيد آخر. والقيود هي تنفيذ قاعدة البيانات لقواعد الأعمال، لذلك فهم بالتأكيد شيء يجب تعريفه على جانب قاعدة البيانات من الأشياء.

كما هو مثال. يمكنك تحديد قيد الشيك على عمود بحيث تكون القيم التي يمكن أن تقبلها هي "Y" و "n" فقط. ينقذ طلبك من الاضطرار إلى التعامل مع "y" و "n" أو حتى "1" و "0". يؤكد قيود الاختيار أن تتوافق بياناتك بالمعايير المتوقعة. يمكن إنشاء رمز التطبيق الخاص بك افتراضات صالحة حول طبيعة البيانات التي يجب أن تتعامل معها.

تعريف طول العمود في نفس القارب. أنت تعلن شيئا ما ليكون varchar2 (10) لأنك لا ترغب في قبول إدخال "ABC123ZYX456" (لأي سبب من الأسباب!)

في أستراليا، أعرف أعمدة الدولة ليكون Varchar2 (3) لأنني لا أريد أن يطبق الناس في "نيو ساوث ويلز" أو "جنوب أستراليا". تعريف العمود يجبره كثيرا على إدخاله ك "NSW" و "SA". وبهذا المعنى، فإن varchar2 (3) هو مجرد قيود للتحقق تقريبا كما يحدد حاليا تسجيل الدخول ('NSW'، 'SA'، 'Vic' إلخ).

باختصار، أطوال الأعمدة المناسبة هي وسيلة لتشفير قواعد الأعمال. انهم شكل آخر من أشكال القيد. أنها تجلب كل مزايا القيود (وتعاني من العديد من العيوب نفسها). ويضمنون، إلى حد صغير، درجة من "نظافة البيانات" أن القيود "المناسبة" تساعد في ذلك أيضا.

لا أشتري الحجة، إما، أنه من الأفضل أن تلتصق بهذه الأنواع من الأشياء في تطبيق العميل لأنه من الأسهل تغيير هناك. لديك 20،000 شخص يستخدمون تطبيقا، وهذا هو 20000 تحديث. لديك قاعدة بيانات واحدة، هذا تحديث واحد. "أسهل في تغيير وسيطة تطبيق العميل"، إذا كان هذا صحيحا، من المحتمل أن تعني قاعدة البيانات التي تعامل فقط كجداول عملاقة مع جميع المنطق الذكي الذي يتم التعامل معه في رمز العميل. إنها مناقشة كبيرة لديك، ولكن نظرا لأن جميع RDBMSes تتيح لك تحديد القيود وهلم جرا في قاعدة البيانات نفسها، من الواضح جدا أن هناك على الأقل حالة جديرة بالاهتمام التي يجب تقديمها من المنطق الأساسي الذي ينتمي إلى الخلفية.

Answer 2

لقد سمعت محسن الاستعلام هل خذ طول فارغة في الاعتبار، على الرغم من أنني لا أستطيع إيجاد مرجع.

تحديد طول Varchar يساعد في التواصل نية. المزيد من الأطراف المحددة، كلما كانت البيانات أكثر موثوقية.

Answer 3

فلماذا يحاول الناس جعل أعمدةهم صغيرة قدر الإمكان؟ أنا لا أؤمن بجعلها صغيرة قدر الإمكان، ولكن تحجيمها بشكل مناسب. بعض الأسباب لصنع (n) varchars أصغر بدلا من أكبر:

1) مع حقل أكبر، يجب أن تكون جميع العملاء الذين يستخدمون قاعدة البيانات قادرين على التعامل مع الحجم الكامل. على سبيل المثال، قم باتخاذ نظام يحمل عنوان الولايات المتحدة مع 255 حرفا لكل حقل: (مماثلة ل TDWTF التي تشير إليها، أعتقد.)

• الاسم الأول
• الكنية
• العنوان الأول
• سطر العنوان 2
• مدينة
• حالة
• الرمز البريدي

الآن ستحتاج شاشات إدخال البيانات الخاصة بك إلى السماح وإظهار 255 حرفا لكل حقل. ليس من الصعب، ولكن من غير المحتمل أن تبدو لطيفة مع فواتير طباعة الحقول الكبيرة، ستحتاج إلى منطق كسر الخط للتعامل مع الحقول الكبيرة. اعتمادا على الأداة، وليس هذا صعبا.

لكنني لا أريد أن تكون مشكلة تنسيق عنوان مظروف يمكن أن يكون لها 255 حرفا لكل من تلك الحقول أو أي واحد من تلك الحقول فقط. هل ستكون اقتطاع إذا كان الحقل طويلا لتناسب؟ شخص عظيم لديه خط العنوان 1 من "رقم البيت رقم السطر ... بلاه بلاه بلاه ... شقة رقم 111." وسوف تخلف عن رقم الشقة الهام. هل ستهرب؟ كم الثمن؟ ماذا لو كنت لا تستطيع أن تناسبها في المربع الصغير من الفضاء على المغلف؟ رفع استثناء ولديك شخص حرف يده؟

2) في حين أن 10 أحرف من البيانات التي عقدت في varchar (50) مقابل varchar (255) لا تؤثر الحجم أو السرعة، فإن السماح لتسمح 255 حرفا بتأخذ مساحة أكبر. وإذا كانت جميع الحقول هي تلك الحقول الكبيرة التي يمكنك الضغط على حدود الحجم في SQL Server 2000. (لم أقرأ في عام 2005 و 2008 لمعرفة ما إذا كان بإمكانهم التعامل مع الصفوف أكبر من صفحة واحدة.) ومع Oracle لك الأحجام الكبيرة المسموح بها تحدث أن يحدث إذا كان شخص ما يستخدم فعلا جميع الأحرف المتاحة.

3) الفهارس لها حدود حجم أكثر صرامة ثم صفحات ورقة. يمكنك تحديد الفهارس، خاصة الفهارس المركبة، إذا قمت بإنشاء Varchars كبيرة جدا.

---

من ناحية أخرى، لدي مجموعة طويلة 1 لعنواني، وقد شعرت بالإحباط عن طريق مواقع الويب التي لا تسمح لكما بتكامل.

Answer 4

يتم تمييز واحد مهم بين تحديد حد كبير بشكل تعسفي [على سبيل المثال VARCHAR(2000)]، واستخدام نموذج بيانات لا يتطلب حد [على سبيل المثال VARCHAR(MAX) أو TEXT].

قواعد postgresql كل طولها الثابت VARCHARS على أنه غير محدود TEXT اكتب، وتقرير ديناميكيا لكل قيمة كيفية تخزين القيمة، بما في ذلك تخزينها خارج الصفحة. المواصفات الطول في هذه الحالة هو حقا مجرد قيد، واستخدامه مثبط بالفعل. (المرجع)

تتطلب DBMSs الأخرى للمستخدم تحديد ما إذا كانت تتطلب "محمولة"، خارج الصفحة، تخزين، عادة مع تكلفة مرتبطة بالراحة و / أو الأداء.

إذا كانت هناك ميزة في استخدام VARCHAR(<n>) على VARCHAR(MAX) أو TEXT, ، يتبع أنه يجب عليك تحديد قيمة ل <n> عند تصميم جداولك. على افتراض وجود بعض أقصى عرض صف جدول الجدول، أو إدخال الفهرس، يجب تطبيق القيود التالية:

1. <n> يجب أن يكون أقل من أو يساوي <max width>
2. إذا <n> = <max width>, ، يمكن أن يكون الجدول / الفهرس عمود واحد فقط
3. بشكل عام، يمكن أن يكون الجدول / المؤشر فقط <x> الأعمدة حيث (في المتوسط) <n> = <max width> / <x>

لذلك ليس القضية التي قيمة <n> يتصرف فقط كقيد، واختيار <n> يجب أن تكون جزءا من التصميم. (حتى لو لم يكن هناك حد صعب في DBMS الخاص بك، فقد يكون هناك أسباب أداء للحفاظ على العرض في حدود معين.)

يمكنك استخدام القواعد المذكورة أعلاه لتعيين أقصى قيمة ال <n>, بناء على الهندسة المعمارية المتوقعة لجدولك (مع مراعاة تأثير التغييرات المستقبلية). ومع ذلك، فإنه يجعل أكثر منطقية لتحديد الحد الأدنى قيمة ال <n>, ، بناء على المتوقع بيانات في كل عمود. على الأرجح، سوف تتوسع إلى أقرب "عدد مستدير" - على سبيل المثال سوف تستخدم دائما أيضا VARCHAR(10), VARCHAR(50), VARCHAR(200), ، أو VARCHAR(1000), ، أيهما أفضل نوبة.

Answer 5

إجابة بسيطة على هذا في رأيي هي حقيقة أنه لا يمكنك استخدام هذا العمود كإجراء فهرس، إذا كنت بحاجة إلى أي فهرسة، فهي مجبرة بشكل أساسي على استخدام FOXTEXT ... هذا فيما يتعلق باستخدام عمود Varchar (MAX). في أي حال، فإن أعمدة "التحجيم الصحيحة" تجعل الكثير من المعنى كلما كنت [قد] ترغب في تطبيق أي فهرسة؛ قد يكون تحديث أعمدة الطول المتغيرة مناورة مكلفة لأن هذه غير مصنفة في مكانها ويمكن / ستؤدي إلى إجراء بعض التجزئة.

كل ذلك فيما يتعلق ب MS SQ-Server.

Answer 6

سأجيب على سؤالك بالسؤال: إذا لم يكن هناك فرق في DBMS بين Varchar (50) و Varchar (255)، فلماذا تتيح لك DBMS تقديم تمييز؟ لماذا لا تقول DBMS ببساطة "استخدام varchar لأحرف xxx، والنص / clob / etc. لأي شيء أكثر من ذلك." بالتأكيد، ربما قد يحافظ Microsoft / Oracle / IBM على تعريف الطول لأسباب تاريخية، ولكن ماذا عن DBMS "مثل MySQL الذي يحتوي على تخزين متعددة - لماذا يقوم كل واحد بتنفيذ أطوال عمود أحرف محددة؟

Answer 7

إذا كنت ذاهبا إلى طباعة التسميات، فأنت عادة ما تريد أن تكون السلسلة لم تعد أكثر من 35 حرفا. هذا هو السبب في أنك تريد التحكم في حجم Varchar الذي ستعمل فيه قبول الأسطر التي سيتم استخدامها لطباعة الملصقات.

Answer 8

إذا سمحت أن تكون طول البيانات أكثر من 255 شخصا ويرتبط شخص ما بالبيانات من خلال MS Access، فلا تتمكن البيانات من استخدامها للانضمام إلى الجداول (تأتي في حقل مذكرة). إذا تم تصدير البيانات إلى Excel، فستقتصر على 255 حرفا لكل حقل. يجب مراعاة التوافق مع البرامج الأخرى عند إنشاء مجموعات البيانات.
التحكم في جودة البيانات هو كل شيء عن السيطرة على البيانات التي تدخل بيئتك. ماذا تحتاج لتخزين هذا أكثر من 255 حرفا؟ هناك أوقات تحتاج البيانات إلى أن تكون أكثر من 255 حرفا، ولكن يجب أن تكون بعيدة وعدد قليل من المعلومات ويجب استخدامها كمعلومات تكميلية داعمة لحقل يمكن استخدامها للتحليل