it-swarm.asia

لماذا يجب إنشاء عمود معرف عندما يمكنني استخدام الآخرين كحقول رئيسية؟

تكرار محتمل:
لماذا تستخدم int كمفتاح أساسي لجدول البحث؟

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

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

لقد رأيت الأشخاص يستخدمون حقول معرّف عدد صحيح لكل شيء ولا أحد يحكم على هذه الطريقة

  • تبدو "فعالة"
  • يتم استخدام حقل رقم ويبدو أكثر برودة بسبب حجمه لكل صف في الذاكرة

لقد بدأت أعتقد أن حقل معرّف إضافي يقوم فقط بإنشاء بيانات مكررة بدون فائدة فعلية. فلماذا أقوم بإنشاء عمود معرف عندما يمكنني استخدام أعمدة أخرى كحقول رئيسية؟

  • إذا كان حقل المعرّف الخاص بك 32 بت ، فإنه يعادل 4 ASCII حرف بالفعل.
  • إذا كان حقل المعرّف الخاص بك هو 64 بت عددًا صحيحًا ، فإنه 8 أحرف سلسلة لا يوفر في الواقع هذا القدر الكبير من الذاكرة (ما هو ضمني هنا هو الذاكرة المستخدمة في المقارنة. عمود المعرّف الإضافي يضيف بالفعل إلى الذاكرة المستخدمة (محرك الأقراص الثابتة وذاكرة الوصول العشوائي))
  • يضاعف حقل المعرّف الإضافي تكلفة الفهرسة لأنك ستفهرس أيضًا حقلًا فريدًا يمكنك استخدامه كمفتاح أساسي.
  • تقوم بعمل روابط إضافية إذا كنت بحاجة إلى البيانات التي يمكن أن تستخدمها كمجال رئيسي ، على سبيل المثال ، إذا قمت بتخزين معرف مستخدم فريد في منشور مدونة واحد ، لإظهار اسم المؤلف ، تقوم بإجراء استعلام انضمام ، إذا كان حقل المفتاح الخاص بك هو اسم المؤلف ، فلن تحتاج إلى الانضمام لأنك تقوم بتخزين البيانات ذات الصلة في جدول نشر المدونة. حقل مفتاح خارجي ببيانات ذات معنى يقلل من الحاجة إلى استعلام فرعي أو انضمام

enter image description here

  • إنشاء حقل معرّف إضافي "يضيف" إلى حمل الذاكرة ، إنه ليس بديلاً لحقل سلسلة فريد ، فأنت لا تستبدل حقل char-varchar بعدد صحيح ، فأنت تضيف إضافي العمود وينشئ تدفق بيانات إضافي . لذلك يجب إجراء مقارنة بين مخزن البيانات بين "سلسلة" و "int + string". إن إضافة حقل معرف صحيح لا يوفر مساحة.

من ناحية أخرى

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

موارد إضافية:

  1. مقارنة مفاتيح البديل البديل الطبيعي

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

50
Uğur Gümüşhan

1 - إنه أسرع. A JOIN على عدد صحيح أسرع بكثير من JOIN في حقل سلسلة أو مجموعة من الحقول. إن مقارنة الأعداد الصحيحة أكثر من السلاسل.

2 - إنه أبسط. من الأسهل بكثير تعيين العلاقات استنادًا إلى حقل رقمي واحد عن مجموعة من الحقول الأخرى لأنواع البيانات المختلفة.

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

4 - إنه أكثر كفاءة إذا قمت بالتجميع في حقل int (زيادة تلقائية) ، فإنك تقلل التجزؤ وتقلل الحجم الإجمالي لمجموعة البيانات. هذا يبسط أيضًا الفهارس اللازمة لتغطية علاقاتك.

تحرير

إلى النقاط المحددة التي أضفتها للتو:

1 و 2 - لا يزال من الأسرع بكثير مقارنة int من سلسلة اعتبارات الفضاء جانبا. أنت أيضا تتجاهل بشكل ملائم النفقات العامة اللازمة لتخزين طول الحقول المتغيرة الطول (عادة 2 بايت لكل حقل لكل صف).

3 - إذا قمت بالتجميع على حقل ID فلن يضيف أي شيء إضافي. يوفر مساحة لأنك تستخدم معرف صف أكثر كفاءة.

4 - ثم عندما يقوم هذا الشخص بتغيير اسم المستخدم الخاص به ، تنقطع روابطك.

5 - أنت حقا لا تعرف ما الذي تتحدث عنه هنا. يجب عليك تخزين البيانات ، هذا صحيح ، ولكن أكثر فعالية بكثير للفهرسة و JOIN في int من على مجموعة من الحقول الأخرى.

41
JNK

لأن الناس تعلموا من التجربة أن استخدام مثل هذه المجالات يؤدي إلى مشاكل.

لقد قمت بتطوير تطبيقات قواعد البيانات لمدة 20 عامًا. والأهم أنني قضيت خمس سنوات في العمل مع مستودعات البيانات. في الأيام الأولى ، بدا اختيار حقل آخر على ما يرام. ثم وجدنا سجلات مكررة ، وأحيانًا كانت عمليات التحقق الفريدة مفقودة ، وأحيانًا (بشكل متكرر) قدم المستخدمون معلومات مختلفة تحتاج الآن للدمج ، أو أيا كان ، وكان دمج السجلات وإدارتها كابوسًا.

حتى (أو حتى بشكل خاص!) عندما يكون المعرف "يبدو" فريدًا ، فقد يتبين أن هذا ليس صحيحًا. على سبيل المثال: رقم الضمان الاجتماعي الأمريكي. يجب أن تكون فريدة بالنسبة للشخص ، أليس كذلك؟ بالتأكيد ، ولكن ماذا لو تم إدخال بعض السجلات بشبكات SSN التي أخطأ المستخدمون في الماضي في كتابتها؟ الآن يمكن أن تكون هناك مشكلات تعارض مع أرقام جديدة صالحة يتم إدخالها للسجلات الجديدة. ملاحظة جانبية هي أنه لا يجب أبدًا عرض المفاتيح الأساسية لأنها تؤدي إلى افتراضات المستخدم بشأنها كما أنها ليست جيدة لأفضل نموذج أمان لعناوين URL لمواقع الويب.
ضع في اعتبارك دائمًا - هل سيضع المستخدم إشارة مرجعية على عنوان URL هذا ويتوقع أن يعمل في المستقبل؟

لذلك تعلم الناس:

لا تستخدم "مفتاحًا بديلاً" (مثل SSN) كمفتاح أساسي عندما يكون البديل له قيمة أو معنى "أي" تجاري.
بدلاً من ذلك ، استخدم مفتاحًا أساسيًا فريدًا وغير مشتق من بيانات التطبيق.

20
Michael Durrant

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

ولكن إذا كان لديك جدول تستخدمه لعلاقة كثير مع كثير ، فلا حاجة لذلك. لنفترض أن لديك الجدولين التاليين:

أخبار الجدول id integer title varchar item text

علامات الجدول معرف عدد صحيح varchar

لكل عنصر في الأخبار ، تريد إضافة علامة واحدة أو أكثر ، بحيث تقوم بإنشاء الجدول:

جدول news_tags news_id عدد صحيح tag_id عدد صحيح

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

12
Michiel van Vaardegem

يقوم معظم الأشخاص بالتخلف عن استخدام INT المتزايد تلقائيًا لمفتاحهم الأساسي نظرًا لأنه أبسط طريقة لتحديد الصف ، خاصة عندما يكون لديك علاقات بين الجداول التي تحتاج إلى تعريف.

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

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

في العالم الطبيعي ، لا يتم تعريف الأشياء بمعرف فريد ، ولكن بعلاقتها مع الكيانات الأخرى. مجال id هو في الحقيقة مجرد قطعة أثرية لقواعد البيانات العلائقية. هذا هو أساس مشكلة تخطيط علاقة الكائن بالكامل (ORM).

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

4
hafichuk

إذا كان بإمكانك استخدام حقول أخرى كمفاتيحك الأساسية ، فهذا جيد. ومع ذلك ، نظرًا لأنك وضعت علامة على هذا ضمن [sql-server] ، فسأتمكن من إضافة بعض المعلومات ...

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

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

  • لا يجب أن تكون أعمدة المعرّف دائمًا أعمدة هوية فقط. يمكنك تخزين date_id (لبعض الجداول التي من المنطقي القيام بذلك) وإذا كانت فريدة (مثلما قلت .. على سبيل المثال لديك جدول حيث صف واحد = يوم واحد) ، يمكنك تطبيقه كمفتاح أو فهرس

  • عندما لا يكون لديك عمود create_date/entry_date وتحتاج في أي وقت إلى التحقق من البيانات بالترتيب الذي تم إدخالها به .. فإن وجود عمود معرّف كهوية يجعل ذلك ممكنًا.

  • يمكن أن يعمل المعرّف كمفتاح خارجي أيضًا.

1
Nonym

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

غالبًا ما يكون البحث أكثر فعالية على مفتاح رقمي.

0
Paul Croarkin