أفضل طريقة لتخزين البيانات في قاعدة البيانات عندما لا تعرف النوع

Question

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

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

أحد الحلول الممكنة هو جعل جدول FieldValue يحمل حقلًا واحدًا لكل نوع قيمة ممكن. الآن سيكون هذا بالتأكيد زائداً ، لكن على الأقل سأحصل على القيمة المخزنة في شكلها الصحيح - تبسيط الاستعلامات لاحقًا.

FieldValue
----------
Id
DataFieldId
IntValue
DoubleValue
BoolValue
DataValue
..

الاحتمال الآخر هو مجرد تخزين كل شيء كسلسلة ، وإلقاء هذا في الاستعلامات. أنا أستخدم .NET مع nhibernate ، وأرى أنه على الأقل هنا هناك إسقاط. البث يمكن استخدامه لإلقاء سلسلة على سبيل المثال إلى int في الاستعلام.

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

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

Answer 1

لا يوجد خيار "السحر" الثالث: يحدد موقفك المحدد كيف تريد المتابعة.

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

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

كما قلت ، يعتمد ذلك على ما إذا كان نوع الاستفسارات التي تحتاج إلى تشغيلها ، ونوع الأداء الذي تحتاجه وما إلى ذلك.

Answer 2

سحب الفكرة من تخزين البيانات متعددة المستأجرين ، يمكنك استخدام فكرة قيم "اسم الزوج" كما هو موضح في MSDN. أعتقد بطريقة ما أن هذه المقالة ستكون أكثر فائدة بصرف النظر عن القسم المحدد.

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

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

Answer 3

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

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

Answer 4

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

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

الايجابيات

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

سلبيات

• لا يمكن أن ينفذ DB أنه لم يتم تحديد أكثر من قيمة واحدة (رمز إضافي للتحقق من الاستثناءات)
• لا يمكن لـ DB أن تنفذ أن واحدًا على الأقل ليس فارغًا (رمز إضافي للتحقق من القيم الحقل دون أي قيمة)
• يتطلب إضافة دعم نوع البيانات الجديد تغيير جميع البيانات الموجودة (إضافة قيمة فارغة على الأعمدة).

إذا كنت عالقًا مع نموذج مخصص > مجال->قيمة الحقل أود أن أقترح إنشاء جدول واحد لكل قيمة الحقل. على سبيل المثال

IntFieldValue
-------------
Id
DataFieldId
Value

DecimalFieldValue
-------------
Id
DataFieldId
Decimal


DateFieldValue
-------------
Id
DataFieldId
Date

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