سؤال

فقط للتوضيح ، من خلال تحديد شيء مثل Varchar (45) يعني أنه يمكن أن يستغرق 45 حرفًا كحد أقصى؟ أتذكر أنني سمعت من شخص ما قبل بضع سنوات أن الرقم الموجود في قوسين لا يشير إلى عدد الشخصيات ، ثم حاول الشخص أن يشرح لي شيئًا معقدًا تمامًا لا أفهمه وأنسى بالفعل.

وما هو الفرق بين Char و Varchar؟ لقد بحثت قليلاً وأرى أن Char يمنحك أقصى حجم العمود ومن الأفضل استخدامه إذا كانت بياناتك تحتوي على حجم ثابت واستخدام Varchar إذا كان حجم البيانات الخاص بك يختلف.

ولكن إذا كان يمنحك الحد الأقصى لحجم عمود جميع بيانات هذا العمود ، أليس من الأفضل استخدامه عندما يختلف حجم البيانات الخاص بك؟ خاصة إذا كنت لا تعرف حجم حجم البيانات الخاص بك. يحتاج Varchar إلى تحديد الحجم (Char لا يحتاج حقًا إلى صحيح؟) ، أليس أكثر مزعجًا؟

هل كانت مفيدة؟

المحلول

عليك أيضًا تحديد الحجم مع CHAR. مع CHAR, ، قيم الأعمدة مبطنة بمسافات لملء الحجم الذي حددته ، بينما مع VARCHAR, ، يتم تخزين القيمة الفعلية التي حددتها فقط.

فمثلا:

CREATE TABLE test (
    char_value CHAR(10),
    varchar_value VARCHAR(10)
);

INSERT INTO test VALUES ('a', 'b');

SELECT * FROM test;

ما سبق سيختار "أ" char_value و "ب" ل varchar_value

إذا كانت كل القيم الخاصة بك بنفس الحجم ، CHAR ربما يكون اختيارًا أفضل لأنه سيتطلب مساحة تخزين أقل من VARCHAR. هذا بسبب VARCHAR يخزن كل من طول القيمة والقيمة نفسها ، في حين CHAR يمكن فقط تخزين قيمة (الحجم الثابت).

نصائح أخرى

ال وثائق MySQL يقدم شرحًا جيدًا لمتطلبات التخزين لأنواع البيانات المختلفة.

على وجه الخصوص ، لسلسلة من الطول ل ، أ CHAR(M) سيأخذ نوع البيانات (M XC) بايت (حيث C هو عدد البايتات المطلوبة لتخزين حرف ... وهذا يعتمد على الأحرف المستخدمة). أ VARCHAR(M) سوف يستغرق (L + 1) أو (L + 2) اعتمادًا على ما إذا كان M <= 255 أو> 255.

لذلك ، يعتمد الأمر حقًا على المدة التي تتوقع أن تكون فيها سلاسلك ، وما هو التباين في الطول.

NB: لا يناقش الوثائق تأثير مجموعات الأحرف على متطلبات التخزين لـ a VARCHAR يكتب. لقد حاولت أن أقتبس من ذلك بدقة ، لكن تخميني هو أنك ستحتاج إلى مضاعفة طول السلسلة من خلال عرض بايت الحرف وكذلك للحصول على متطلبات التخزين.

يصبح char و varchar في الواقع غير ذي صلة إذا كان لديك حقل طول متغير واحد فقط في الجدول الخاص بك ، مثل varchar أو النص. سوف MySQL تغيير جميع char تلقائيا إلى varchar.

يمكن أن يمنحك سجل الطول/الحجم الثابت أداءً إضافيًا ، ولكن لا يمكنك استخدام أي أنواع حقل طول متغيرة. والسبب هو أنه سيكون أسرع وأسهل على MySQL للعثور على السجل التالي.

على سبيل المثال ، إذا قمت بعمل SELECT * FROM TABLE 10 ، يتعين على MYSQL مسح ملف الجدول للسجل العاشر. هذا يعني العثور على نهاية كل سجل حتى تجد نهاية السجل العاشر. ولكن إذا كان لدى الجدول الخاص بك سجلات طول/حجم ثابت ، فإن MySQL بحاجة فقط إلى معرفة حجم السجل ثم تخطي 10 x #bytes.

إذا كنت تعرف أن العمود سيحتوي على عدد صغير وثابت من chars ، فاستخدم char ، وإلا استخدم varchar. عمود char مبطن لطول الحد الأقصى.

لدى Varchar النفقات العامة الصغيرة (4-8 بايت اعتمادًا على RDBMS) ، ولكن لا يستخدم إلا العدد الفعلي للأشجار المخزنة.

بالنسبة للقيم التي تعرف أنها ستكون ثابتة ، على سبيل المثال لأرقام الهواتف والرموز البريدية وما إلى ذلك ، من الأمثل استخدام "char" بالتأكيد.

الأشياء المعقدة التي لا تتذكرها هي أن 45 تشير إلى البايتات ، وليس chars. ليس هو نفسه إذا كنت تستخدم تشفير حرف متعدد الأطوار. في Oracle ، يمكنك تحديد البايت أو chars بشكل صريح.

varchar2(45 BYTE)

أو

varchar2(45 CHAR)

نرى الفرق بين البايت و char في أنواع بيانات الأعمدة

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top