تصميم قاعدة البيانات فيما يتعلق بالإدخالات الديناميكية - صف واحد أم صفوف متعددة؟

Question

لقد كنت أحاول تصميم مخطط قاعدة بيانات لمشروع جانبي ولكني لم أتمكن من إنتاج أي شيء يناسبني.أنا أستخدم ASP.Net مع LINQ للوصول إلى البيانات الخاصة بي:

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

إذا كنت سأضع هذا الإدخال في صف واحد، فإنه سيعادل بسهولة أكثر من 30 عمودًا (الحد الأدنى)، على سبيل المثال.item_1_name (Ref) item_1_weight item_1_volume item_2_name ...إلخ...

ولا يمكنني ببساطة تحويل هذه الأعمدة إلى جداول مرجعية لأن كل خاصية يمكن أن تتراوح بشكل أساسي من 1 إلى 400+.

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

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

هل هناك شيء أتجاهله في تصميمي/هل هناك طريقة أفضل وأكثر فعالية للقيام بذلك؟

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

Answer 1

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

CREATE TABLE Items (
  user_id               INTEGER NOT NULL,
  item_id               INTEGER NOT NULL DEFAULT 1,
  numeric_property1     INTEGER,
  numeric_property2     INTEGER,
  referential_property  INTEGER,
  PRIMARY KEY (user_id, item_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
                        ON DELETE CASCADE,
  FOREIGN KEY (item_id) REFERENCES num_items(item_id),
  FOREIGN KEY (referential_property) REFERENCES some_other_table(some_column)
);

أعرض طاولة num_items أعلاه، والذي يحتوي على الأرقام من 1 إلى 10 إذا كنت تريد تقييد المستخدمين بـ 10 عناصر على الأكثر:

CREATE TABLE num_items (item_id INTEGER NOT NULL );
INSERT INTO num_items (item_id) 
  VALUES (1), (2), (3), (4), (5), (6), (7), (8), (9), (10);

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

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

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

Answer 2

واستخدام جدول عنصر واحد:

وحاليا، itemIndex، isReference، numericValue، referenceValue

وهذه الطريقة قيمة item_3_name للمستخدم 999 يترجم إلى

و999،3، صحيح، فارغة، القيمة

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

Answer 3

وتصميم قاعدة البيانات السليم سيكون لتخزين لكل مستخدم / البند في صف منفصل. وسيكون هذا أسهل بكثير للعمل مع، ويزيل قيود تعسفية من 10 مادة. لن أقول انها سوف تنمو "عميق فلكية"، سيكون هناك حوالي 10 × (عدد المستخدمين) الصفوف.