هل هذه جداول محددة تحتاج بديلة المفاتيح ؟

Question

الخلفية

لدي هذه الجداول

+-------------------------+  +------------------------+
|Airport                  |  |Country                 |
|-------------------------|  |------------------------|
|airport_code string (PK) |  |country_code string (PK)|
|address string           |  |name string             |
|name  string             |  +------------------------+
+-------------------------+

+-------------------------+
|Currency                 |
|-------------------------|
|currency_code string (PK)|
|name string              |
+-------------------------+

airport_code هو اتحاد النقل الجوي الدولي (اتحاد النقل الجوي الدولي ) رمز المطار, ، يمكنك ان ترى لهم في العلامات الأمتعة عند السفر بالطائرة.

country_code هو ISO 3166-1 A3 القياسية رمز البلد, يمكنك أن ترى لهم في الالعاب الاولمبية.

currency_code هو IS0 417 القياسية 3-حرف رمز العملة, ، يمكنك ان ترى لهم في صرف العملات الدولية لوحات العرض.

الأسئلة

هؤلاء الطبيعية PKs جيدة بما فيه الكفاية ؟

يستخدم العالم تحترم المعايير المقبولة من قبل كل الصناعات جيدة بما فيه الكفاية بالنسبة PKs ?

هل هذه الجداول تحتاج البدائل بغض النظر عن ماذا ؟

Answer 1

لا، لا يفعلون ذلك.هذه المفاتيح هي بالتأكيد جيدة بما فيه الكفاية!

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

القيود التي تعاني من القيود التي تتعلق ب PKS أنها ثابتة وعددية رقمية ليست جزءا من نموذج العلائقية (CODD's) أوأي معيار SQL (ANSI أو غيرها).

Answer 2

أعتقد تحتاج هو كلمة قوية جدا ، بمعناه الدقيق ، الجداول ربما لا تحتاج البديل مفاتيح.

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

+-------------------------+  +------------------------+
|Airport                  |  |Country                 |
|-------------------------|  |------------------------|
|airport_id       int (PK)|  |country_id     int (PK) |
|iata_airport_code string |  |iso_country_code string |
|icao_airport_code string |  +------------------------+
|faa_identifier    string |  
|address           string |  
|name              string |  
+-------------------------+

+-------------------------+
|Currency                 |
|-------------------------|
|currency_id int (PK)     |
|iso_currency_code string |
|name string              |
+-------------------------+

وبعبارة أخرى ، ما لم تكن تلك الصناعة القياسية رموز أصلا المهم إلى طلبي, أنا لا استخدام لها كما PK من الجداول.انهم مجرد تسميات.معظم الجداول الأخرى المحتمل أن يكون بديل المفاتيح على أي حال ، هذا الإعداد إضافة الاتساق إلى نموذج البيانات.تكلفة 'مضيفا' البديلة المفاتيح هو الحد الأدنى.

تحديث استنادا إلى بعض التعليقات:

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

ومع ذلك ، إذا كان الجدول هو جدول بحث في زوايا قليلة من التطبيق ، الأهمية النسبية IATA رموز قد لا تبرر مثل هذه البقعة البارزة في قاعدة البيانات الأساسية.بالتأكيد, قد تضطر إلى إجراء إضافي المشاركة في عدد قليل من الاستفسارات هنا وهناك ، ولكن هذه الجهود قد تكون تافهة بالمقارنة مع الجهد سيستغرق البحث إلى التأكد من أنك تفهم تماما آثار من صنع الاتحاد الدولي للنقل الجوي رموز حقل المفتاح الأساسي.في بعض الحالات, ليس فقط لا يهتم ، ولكن أنا لا أريد أن الرعاية عن الاتحاد الدولي للنقل الجوي رموز.@جيمس سنيل التعليق أدناه هو خير مثال على ما كنت قد لا تريد أن لديك ما يدعو للقلق التي تؤثر على PK من الجداول.

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

تحديث استنادا إلى مزيد من البحث:

حسنا, الفضول بت لي و قررت أن تفعل بعض البحوث على IATA رموز المطار من أجل المتعة ، بدءا من الروابط الموجودة في السؤال.

كما اتضح ، IATA رموز ليست عالمية موثوقة مثل السؤال يجعل لهم أن يكون.وفقا هذه الصفحة:

استخدام معظم البلدان أربعة أحرف منظمة الطيران المدني الدولي رموز, لا IATA رموز في الرسمية منشورات الطيران.

وبالإضافة إلى ذلك, IATA رموز منظمة الطيران المدني الدولي رموز متميزة من FAA رموز معرف, التي هي طريقة أخرى لتحديد المطارات.

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

في هذه الحالة ، أشعر قاعدة البيانات سيكون أفضل تنظيما وأكثر استقرارا و أكثر مرونة من خلال التخلي عن الاتحاد الدولي للنقل الجوي رموز (أو أي طرف 3rd, يحتمل أن تكون قابلة للتغيير رمز) كمفتاح أساسي مرشح واستخدام بديل الرئيسية.وبذلك لا يمكن التخلي عن أي المزالق المحتملة التي قد تنشأ بسبب المفتاح الأساسي للاختيار.

Answer 3

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

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

وجود bigint، int، smallint، tinyint أو أي نوع من البيانات يشبه عدد صحيح قد يوفر لك بعض المتاعب أسفل الطريق.

فقط 2 سنتات

تحديث:

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

مشروع كبير - يستخدمه الآلاف، عشرات الآلاف، ملايين المستخدمين يوميا. شيء تراه لشركة وطنية / دولية مع قاعدة مستخدم ضخمة.

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

إذا تم استخدام Varchar وهذا يعني أن التباعد ليس موحدا، ما لم تكن البيانات دائما نفس طولها (عند النقطة التي تكون فيها قيمة سحر أكثر فعالية). هذا يجعل البحث أبطأ الفهرس، ومع الخادم مشغول بالفعل بمعالجة الآلاف والآلاف من الاستفسارات في الثانية الآن، يجب أن تضيع الوقت في الذهاب إلى مؤشر غير موحد، والقيام بنفس الشيء مرة أخرى على الإنضمام (وهو أبطأ من يختار منتظم على جدول غير محسن، واتخاذ DWS كمثال حيث يوجد عدد قليل من الأعمال قدر الإمكان لتسريع استرجاع البيانات). أيضا إذا كنت تستخدم UTF التي يمكن أن تعبث مع محرك قاعدة البيانات أيضا (رأيت بعض الحالات).

شخصيا، من تجربتي الخاصة، يمكن أن يؤدي الفهرس المنظم بشكل صحيح إلى زيادة سرعة الانضمام بنسبة ~ 70٪، والقيام بالانضمام إلى عمود عدد صحيح يمكن أن يسرع الانضمام بقدر ما يصل إلى حوالي ~ 25٪ (اعتمادا على البيانات). نظرا لأن الجداول الرئيسية تبدأ في النمو وتستخدم هذه الجداول عليها، فلا تفضل أن تحتل نموذج بيانات عدد صحيحا العمود الذي يحتوي على عدد قليل من البايتات مقابل وجود حقل varchar / char الذي يحتل مساحة أكبر. يتعلق الأمر بتوفير مساحة القرص، وزيادة الأداء والهيكل العام لقاعدة بيانات علائقية.

أيضا، كما ذكر جيمس سنيل:

يجب أن تكون مفاتيح

غير قابلة للتطبيق، وهو ما يرمز مطار IATA بالتأكيد ليس كذلك. يمكن تغييرها في نزوة IATA.

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

Answer 4

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

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

هناك بعض الحالات الخاصة بالولايات المتحدة، حيث تغيرت المعايير بشكل كبير: الترميز البريدي الموسع من 5 - 9 أرقام، اختصارات الدولة إلى رسائل ثابتة ثابتة والتخلص من الفترة (تذكر أن إلينوي كان مريضا؟)، ومعظم العالم يتعامل مع Y2K. إذا كان لديك تطبيق في الوقت الفعلي مع انتشار البيانات في جميع أنحاء العالم الذي يحتوي على مليارات السجلات، فإن التحديثات المتتالية ليست هي أفضل فكرة، ولكن لا ينبغي أن نعمل جميعا في الأماكن التي تواجه هذه التحديات؟ مع هذه البيانات، يمكنك اختبارها لنفسك وتصل إلى إجابة أكثر عرضة.