سؤال

ما هي أفضل طريقة للحفاظ على حقل معرف فريد عبر جداول قاعدة بيانات متعددة؟

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

بعض الأفكار التي أفكر فيها هي:

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

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

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

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

  • طريقة أفضل للتعامل مع هذا لا أعرفها لأنني لست DBA

أيا كان الحل الذي أذهب إليه ، يجب أن أكون قادرًا على التعامل بسهولة مع عدد كبير من السجلات (قاعدة البيانات التي سيتم استبدالها تحتوي على بضعة ملايين السجلات) وهو على خادم MS SQL

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

المحلول

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

سأفعل واحدة مما يلي:

يمكنك بالطبع استخدام عمودين منفصلين في جدول العنوان Froe لكل كيانين. BusinessId و People. يمكن أن يكون لدى FKS NULL ، لذلك سيكون هذا على ما يرام. ويمكنك بعد ذلك تطبيق علاقة FK التي ستمنعك من وجود مشاكل في تكامل البيانات.

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

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

لقد نسيت أحد الاحتمالات ، إذا كان لديك الكثير من العلاقات ، فيمكنك أن يكون لديك معالجة وأعمال وأشخاص ثم بعض الجداول الربطية ، BusinessAddress ، peopleaddress. أنا شخصياً لن أستخدم GUIDS إذا كان لدي خيار آخر حيث يمكنهم إلحاق الأداء.

نصائح أخرى

يمكنك أيضا عكس تفكيرك.

بدلاً من وجود عنوان ، يكون لدى الشخص أو معرف العمل ، فإن الشخص أو العمل لديه معرف العنوان.

هذه طريقة طبيعية للتفكير في ذلك في كتابي ... لدى الشخص عنوان.

هذا ما هو Guids ل.

هناك بعض الأنماط المختلفة للقيام بذلك ، ولكن الأسهل والأكثر مرونة هو استخدام معرفات فريدة (GUIDS) ؛ معظم DBS لديها بعض التسهيلات لبناء هذه (SQL Server هو newID () على سبيل المثال). إنها أكبر من نماذج الهوية الأخرى ، لكنهم سيقومون بالمهمة التي تبحث عنها.

تتيح لك بعض قواعد البيانات أن يكون لديك مفاتيح أجنبية ذات قيم خالية. البعض لا ، ولا يمكنني تذكر ما إذا كان SQL Server يفعل. إذا سمح لك ذلك ، فيمكنك الحصول على عمودين معرّفين في جدول العناوين ، وهو واحد يشير إلى الأشخاص والآخر يشير إلى الشركات. هذا النهج لديه أيضا إيجابيات وسلبيات ؛ واحدة من السلبيات هي أنه ربما يكون مستهجنًا من قبل DBA الخاص بك ، ولكن إذا سمحت قاعدة البيانات الخاصة بك ، فربما تكون واحدة من البدائل.

قم بإنشاء جدول "SuperType" يحدد كل من الشركات والأشخاص ويشير إلى هذا الجدول مع المفتاح الخارجي الخاص بك. هذا نمط شائع للوضع. نرى: نموذج بيانات الحزب.

Guids جيدة كمعرفات فريدة ، لا شيء آخر.
المشكلة مع GUIDS هي حجمها ، خاصة إذا كان DB الخاص بك سيكون ضخمًا.
لا ينبغي استخدامها في الوصلات (الفهرس ، المفتاح الأجنبي ، ...).
كان لدينا تصميم DB الدقيق الذي كان علينا تغييره إلى الأعداد الصحيحة عندما أصبح عدد السجلات كبيرًا جدًا.
أود أن أشير أيضًا إلى أنك بحاجة إلى توخي الحذر مع تصميمك لأشخاص/أعمالك/عناوينك. إنه كثير من العلاقات. يمكن أن يكون لدى الأعمال/الشخص أكثر من عنوان واحد ، ويمكن أن يكون العنوان لعدة شركات/أشخاص ...

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

الأعمال والناس حقًا منفصلين عن العمل؟

ليس لديهم شيء مشترك على الإطلاق ، حتى "اليوم الذي ولدوا فيه"؟

العمل لا يعامل كلاهما على أنه "الأطراف المقابلة"؟

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

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

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