رسم خرائط العقيدة على جدول واحد يحتوي على مفتاح أساسي مكون من 3 حقول

2

أعاني من اختيار التخطيط الصحيح للفئة التالية مثل السيناريو :

The food entity has a composed primary key made of 3 fields plus a name field:
╔════════╦═══════╦════════╦════════════════╗
║ family ║ class ║ sector ║ name           ║ - family INT UNSIGNED NOT NULL
╠════════╬═══════╬════════╬════════════════╣ - class INT UNSIGNED DEFAULT NULL
║ 1      ║ NULL  ║ NULL   ║ Natural        ║ - sector INT UNSIGNED DEFAULT NULL
║ 1      ║ 2     ║ NULL   ║ Greens         ║ - name VARCHAR(200) NOT NULL
║ 1      ║ 2     ║ 1      ║ Spring veggies ║ - PRIMARY KEY (family, class, sector)
║ 1      ║ 2     ║ 2      ║ Spring fruits  ║
║ 1      ║ 2     ║ 3      ║ Summer veggies ║
╚════════╩═══════╩════════╩════════════════╝

هذا الجدول عن فئات الطعام. يمكن أن تكون مطابقة إدخال واحد فقط family + class + sector . كلما زاد ملء الحقول الأساسية ، كلما كان سجل الفئة "أكثر تحديدًا". وجود سجل family + class + sector (بعبارة أخرى ، فئة قطاعية فعلية) سيكون لها والدان ضمنيان: أ / سجل طبقي ، لهما نفس الشيء family و class لكن sector تم تعيينه على NULL ، b / A Family record ، أعلى فئة ، لها نفس القيمة العائلية ولكن كلاهما class و sector تعيين إلى NULL.

سجل قطاعي سيكون لديه 0 أطفال لكن والدان يعنيان $spring_fruit_object->getParents() سيعيد مجموعة من الكيانات الغذائية مثل [natural_hydrated_object, greens_hydrated_object] (بلهفة).

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

كيف ستتعامل مع هذا السيناريو؟ شكرا جزيلا.

1 إجابة

0

(متوقف: هذا يعني أن غذاء واحد مسموح به فقط لكل أسرة + فئة + قطاع. هل أنت متأكد أن هذا ما تريده؟ يبدو غريبا)

Should I add an auto-increment primary key, convert current Primary composed key into a UNIQ index and use simply repository with querybuilder?

IMO ، ينبغي تجنب المفاتيح الأساسية المركبة. قد يكون من المغري استخدامها ، لأنها منطقية ، ولكن:

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

تشير مستندات العقيدة إلى 3 حالات استخدام ( https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/tutorials/composite-primary-keys.html#use-case-1-dynamic-attributes ) ، كلها صالحة ، لكني سأفكر فقط في الحالة 1 ، لأن ذلك يضيف قيمة حقيقية - لا يتعين عليك إنشاء سمات ، يبسط واجهة برمجة التطبيقات.

:مؤلف
فوق
قائمة طعام