المفتاح الخارجي المرجع الجدول المركب

Question

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

في الأساس لدي نوعان ، tblsystemitems و tblClientItems. لدي جدول ثالث يحتوي على عمود يشير إلى "عنصر". المشكلة هي أن هذا العمود يحتاج إلى الإشارة إلى عنصر نظام أو عنصر عميل - لا يهم ذلك. تحتوي عناصر النظام على مفاتيح في نطاق 1..2^31 بينما تحتوي عناصر العميل على مفاتيح في النطاق -1 ..- 2^31 ، وبالتالي لن يكون هناك أي تصادمات أبدًا.

كلما قمت بالاستعلام عن العناصر ، أقوم بذلك من خلال وجهة نظر تقوم بالاتحاد بين محتويات الجدولين.

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

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

Answer 1

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

بالنسبة لاستخدام جدول ثالث لتضمين PKS من كل من جداول العميل والنظام - لا أحب ذلك لأن ذلك يعقد المزامنة بشكل مفرط ولا يزال يتطلب تطبيقي لمعرفة الجدول الثالث.

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

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

انتهى بي الأمر إلى إنشاء جدول واحد فقط ، عناصر. يحتوي العناصر على عمود يسمى "SystemItem" الذي يحدد ، بشكل جيد ، واضحًا. في قاعدة بيانات التطوير / النظام ، حصلت على PK كهوية INT (1،1). بعد إنشاء الجدول في قاعدة بيانات العميل ، يتم تغيير مفتاح الهوية إلى (-1 ، -1). هذا يعني أن عناصر العميل تسير في السلبية بينما تنطلق عناصر النظام بشكل إيجابي.

بالنسبة للتزامن ، أتجاهل بشكل أساسي أي شيء مع (SystemItem = 1) أثناء مزامنة الباقي باستخدام إدراج الهوية. وبالتالي ، فأنا قادر على مزامنة مع تجاهل عناصر العميل وتجنب الاصطدام تمامًا. أنا أيضًا قادر على الرجوع إلى جدول "عناصر" واحد فقط يغطي كل من عناصر العميل والنظام. الشيء الوحيد الذي يجب وضعه في الاعتبار هو إصلاح المفتاح المتجدد القياسي ، لذا فمن النزول لتجنب جميع أنواع إعادة هيكلة الصفحات عندما يقوم العميل بإدراج عناصر جديدة (تحديثات العميل مقابل تحديثات النظام تشبه 99 ٪/1 ٪).

Answer 2

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

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

مع وجود المزيد من Bakcground/سياق ، ربما يكون من الأسهل تحديد الحل الأمثل.

Answer 3

ربما تحتاج إلى جدول يقول tblitems التي ببساطة تخزين جميع المفاتيح الأساسية للجداول. سيتطلب إدخال العناصر خطوتين للتأكد من أنه عند إدخال عنصر في جدول TBLSYSTEMITEMS الذي يتم إدخال PK في جدول TBLITEMS.

الجدول الثالث ثم لديه fk إلى tblitems. بطريقة ما tblitems هو أحد الوالدين لجداول العناصر الأخرى. للاستعلام عن عنصر ما ، سيكون من الضروري إنشاء انضمام بين tblitems و tblsystemitems و tblClientItems.

تحرير مقابل التعليق أدناه] إذا كانت TBLSystemItems و TblClientItems تتحكم في PK الخاصة بهم ، فلا يزال بإمكانك السماح لهم بذلك. من المحتمل أن تدخل في tblSystemItems أولاً ثم إدراجها في tblitems. عندما تقوم بتنفيذ بنية الميراث باستخدام أداة مثل السبات ، ينتهي بك الأمر بشيء من هذا القبيل.

Answer 4

أضف جدولًا يسمى عناصر مع عنصر PK ItemID ، وعمود واحد يسمى itemType = "system" أو "Client" ، ثم يكون لدى ClientItems Table PK (اسم ClientItemId) و SystemItems PK (SystemItemId المسمى) على حد سواء يكون أيضًا fks to items.itemid ، ( هذه العلاقات صفر إلى علاقات واحدة (0-1)

ثم في الجدول الثالث الذي يشير إلى عنصر ، فقط اجعل مرجع قيود FK IteD في هذا الجدول الإضافي (العناصر) ...

إذا كنت تستخدم الإجراءات المخزنة لتنفيذ إدراجات ، فكل ما عليك هو أن تقوم بتخزينها بإدراج عن عناصر إدراج سجل جديد في جدول العناصر أولاً ، ثم باستخدام قيمة PK المولدة تلقائيًا في هذا الجدول ، أدخل سجل البيانات الفعلي في إما SystemItems أو ClientItems (اعتمادًا على أيها) كجزء من نفس مكالمة Proc المخزنة ، باستخدام قيمة (الهوية) التي تم إنشاؤها تلقائيًا والتي تم إدخالها في عمود Itemid Table.

وهذا ما يسمى "التصنيف الفرعي"

Answer 5

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

Answer 6

لدي موقف مماثل في قاعدة بيانات أستخدمها. لدي "مفتاح مرشح" على كل جدول أسميه EntityId. ثم ، إذا كان هناك جدول يحتاج إلى الرجوع إلى عناصر في أكثر من أحد الجداول الأخرى ، فأنا أستخدم EntityID للإشارة إلى هذا الصف. لديّ جدول كيان لتجاوز كل شيء (بحيث يكون INTITYID هو المفتاح الأساسي لجدول الكيان ، وجميع ENTITYID الأخرى هي FKS) ، لكنني لا أجد نفسي باستخدام جدول الكيان في كثير من الأحيان.