إيجابيات وسلبيات قواعد البيانات متعددة القيمة

Question

لقد بدأت للتو وظيفة جديدة حيث سأضطر إلى القيام بقدر لا بأس به من العمل مع قاعدة بيانات متعددة القيم (الكون). ما هي تجربة قاعدة البيانات الصغيرة التي لدي هي في قواعد البيانات العلائقية (SQLServer) وأنا أبحث عن بعض المعلومات غير المتحيزة حول ما تتم مقارنة إيجابيات وسلبيات MVD بقواعد البيانات العلائقية.

كل شخص في المكتب إما يأتي من خلفية قاعدة بيانات علائقية (ويكره الكون) أو كان هنا لسنوات ويحبها.

Answer 1

أولا ، إخلاء المسؤولية. أنا أعمل مع Unidata (أخت DB للكون) وأحيانًا بلوق على ذلك, ، لذلك لا يمكنني الادعاء بأنه غير متحيز تمامًا ؛ سأحاول ، ومع ذلك.

فيما يلي بعض نقاط النظر بالنسبة لك:

• هناك فرق كبير بين SQL DB و DB متعددة 1NF. هذا له إيجابيات وسلبيات لها. يمكن (وعادة ما يكون) الاعتداء ، ولكن هناك أوقات يمكن أن تكون وظيفية للغاية. أكبر فائدة هي أنه يعني أنك لا تحتاج دائمًا إلى جدول انضمام يمكن أن يجعل بعض الاستعلامات أسرع بكثير.

• يقوم بتخزين بيانات التعريف بطريقة جديدة تمامًا عند مقارنتها بـ SQL DBS العادية. كل ملف/جدول لا يحتوي على مخطط خرساني. بدلاً من ذلك ، يحتوي على ملفات "قاموس" واحدة أو أكثر والتي تتكون من السجلات التي تخبرك بكيفية تفسير البيانات. يتيح لك ذلك عدم تخزين تفسيرات متعددة للبيانات فقط (RAW/EXTRACASE/SULCRASE ، الحقول المدمجة ، إلخ) ، ولكنها تتيح لك أيضًا إجراء ما يعادل التعدادات والانضمام. يمكن أن يكون قوي للغاية إذا تم ذلك بشكل صحيح.

• للأسف ، على الرغم من أن المفهوم لديه الكثير من الإمكانات ، إلا أن مجموعة أدوات DBMS غير موجودة. إن التطوير مدفوع ولكن مجموعة صغيرة للغاية من حالات الشركات التي يبدو أنها مدفوعة بعقلية "الحفاظ على الإضاءة" لأنظمة البرمجيات الحالية والشيخوخة التي تم بناؤها عليها. على الرغم من أنه يحتوي على أدوات للتكامل (مثل موصلات .NET ، فإن واجهة ODBC لاستعلامات SQL ، إلخ) لديها مشاكل. على سبيل المثال ، تفتقر واجهة UniObjects .NET إلى أي تحبيب في الأمان (بشكل أساسي كل شيء أو لا شيء).

• إنها ليست مجرد DBMS ، ولكنها أساسًا منصة تطبيق كاملة. على الرغم من أن Unibasic ليس بنفس القدر مثل اللغة القائمة على اللغة ، إلا أنها تتفوق على السراويل من T-SQL ولها تحول سريع لضخ قواعد العمل.

Answer 2

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

يعتمد الأمر حقًا على ما تحاول القيام به ، وكيف تحتاج البيانات إلى تنظيمها ، وما هي الأدوات الأخرى التي لديك. أقضي معظم وقتي في العمل في MV (منتجات الوحي ، في الغالب) ونتعامل مع مجموعات السجلات في 10،000،000+ بانتظام ، والسرعة جيدة.

قوة قاعدة بيانات MV هي عندما تكون البيانات سائلة. نجد أن معظم عملائنا يستخدمونها لتطبيقات مثل المنتجات القانونية والطبية والمالية ؛ التطبيقات التي تكون فيها العلاقات معقدة ويمكن أن تتغير بسرعة وثقل مع مرور الوقت.

قد ترغب في إلقاء نظرة على حركة NO SQL ، التي تشترك في الكثير من نفس المفاهيم ، على الرغم من أن MV وليس SQL ليسوا نفس الشيء.

الجانب السلبي الرئيسي لـ MV أقل في هيكله ، من أدواته. ستجد بشكل عام أنه نظرًا لأن قاعدة المطورين أصغر ، فإن مجموعة الأدوات والمساعدة المتاحة أصغر. قد تجد أيضًا أن اللغة الأساسية المدمجة التي تمنحك معظم العروض تفتقر إلى ترميز نمط الكائن الذي اعتدت عليه. هناك أوقات حتى javaScript تبدو وكأنها لديها المزيد من الوظائف كلغة.

بعد قولي هذا ، نظرًا لأن قواعد بيانات MV هي سلاسل عملاقة في المقام الأول ، فإن معالجة السلسلة للغات ممتازة. إنها رائعة لمعالجة سلسلة HTML و XML مباشرة.

أفترض أن السؤال الكبير لدي ، هل لديك أسئلة محددة؟ لن أفتح حربًا قائلة إنها مثل الانتقال من Windows إلى Linux أو Mac ، أو حتى الانتقال من Debian إلى Red Hat ، لكن الهياكل والأنظمة مختلفة ، لذلك لديها مفاهيم ونقاط القوة والقيود والأغراض المختلفة . إذا حاولت التعامل مع قاعدة بيانات MV مثل SQL (والتي يمكنك) ، فستجد أنها ليست الأنسب. يمكن أن تكون قاعدة بيانات MV سيئة المصممة تمرينًا في الإطفاء. يمكن أن تكون قاعدة بيانات MV مصممة بشكل جيد شيئًا من الجمال.

Answer 3

قواعد بيانات MV تعرف لضغط الأداء الرائع من الخوادم المنخفضة نسبيًا.

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

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

Answer 4

لا توجد إيجابيات وسلبيات على هذا النحو - فهي ببساطة تستخدم طرقًا مختلفة لتخزين القيم. يستخدم الكون محددًا لفصل القيم (IIRC يستخدم Char (254) و Char (253) لتقسيم القيم المتعددة في حقل ، و Char (255) لفصل السجلات الفعلية في ملف البيانات. قد أكون مخطئًا على الرغم من ذلك - لقد مر أكثر من 10 سنوات منذ آخر مرة استخدمتها فيها). يحب بعض الأشخاص طريقة تخزين البيانات هذه ، تمامًا مثلما لا يزال بعض الأشخاص يفضلون السيارات القديمة على تلك الطرازات المتأخرة ، أو يفضل بعض الناس استخدام حصان وعربة بدلاً من سيارة حديثة. (وبطبيعة الحال، هذا هو رأيي فقط).

يعني تخزين قيم متعددة داخل حقل أنه ليس لديك الجدول الإضافي الذي كان قد يستخدمه SQLServer ، فأنت لديك بشكل فعال مستوى من التوحيد. يعد استخدام هذه القيم المتعددة أمرًا سهلاً وجيدًا إذا كنت نستخدم تقنية تسير مع الكون (اعتدنا على استخدام نظام الرياح يسمى Cuebic) ، ولكنه يعزف على pita عند الاتصال بقاعدة البيانات من لغة أخرى مثل C ++ أو VB - أنت بعد ذلك يجب قراءة سجل وفصل القيم بنفسك. هذا يعني أنه كان من الصعب أيضًا البحث على تلك القيم المتعددة.

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

Answer 5

التحجيم إلى الكثير من العناصر (السجلات) في الملفات يعمل بشكل جيد. سيؤدي التحجيم إلى الكثير من القيم أو القيم الفرعية في السجلات إلى إنشاء مشكلات في الأداء. يجب أن يكون تصميم التطبيق حساسًا للحد من القيمة وقوائم القيم الفرعية أسفل عتبة 1000 عدة.

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