الاختيار بين خادم الدليل (قاعدة بيانات AKA LDAP) و RDBMS

Question

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

الخيار الأول كان RDBMS. ومع ذلك بسبب الطبيعة الهرمية لبيانات التكوين ومعيار قابلية التوسيع، بدا خادم الدليل خيارا أفضل. الدوافع التي تستمر مع خادم الدليل هي

1. من الأسهل نموذج البيانات الهرمية في خادم الدليل من RDBMS.

2. من الأسهل أيضا إنشاء / تحديد أنواع الكيان الجديدة التي تغطي نوعا أساسا مع سمات إضافية. هذا جذاب للغاية من نقطة حل المشكلات.

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

بعد حوالي أسبوع من Bootstrapping نفسي على أساسيات LDAP وخوادم الدليل، أنا الآن متشكك بعض الشيء حول اختيار خادم الدليل. أرى بعض القضايا:

1. LDAP أقل تعميم من RDBMS. الكثير من الناس لديهم خبرة مع بعض SQL ويمكن أن تبدأ بشكل أسرع مع RDBMS من خادم الدليل. كما ذكرت سابقا، أخذني أكثر من أسبوع بقليل لتعلم أساسيات LDAP (كيفية إنشاء مخطط، وحدد DIT وإضافة إدخالات وبيانات تصدير ملفات LDIF وما إلى ذلك). هذا مهم لأنه عندما ينضم عضو جديد إلى الفريق، فإنه لا يواجه منحنى التعلم.

2. في المستقبل قد يكون لدينا المزيد من البيانات المراد الحفاظ عليها وتخزينها في قاعدة البيانات. قد لا يكون خادم الدليل خيارا جيدا لهذه البيانات (مثل البيانات أكثر مما يمكن تحديثه بقدر ما يتم قراءته). وجود اثنين من آليات التخزين عبء، في رأيي.

3. في مقدمة أكثر سياسية، لن يتم إلقاء اللوم على / إطلاقها لاختيار RDBMS حتى لو لم يكن مناسبا لهذه المشكلة حاليا. مع خادم الدليل، إذا أصبح النقطة 2 أعلاه حقيقة واقعة، لا أريد الإجابة على السؤال "لماذا لم تفكر في ذلك في وقت سابق؟".

أنا أبحث عن المشورة حول كيفية اتخاذ الاختيار. هل واجه أي شخص موقف مماثل من قبل؟

تحرير 1.: كان لدينا مناقشة حول هذا ضمن المشروع حيث قمت بوضع النقاط الدقيقة التي صنعتها هنا. من المحتمل جدا أن نختار RDBMS دون أي تقييم إضافي بسبب الأسباب التالية:

1. تم اعتبار النقطة 2 أكثر أهمية من أي شيء آخر.

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

3. "لماذا لا RDBMS؟" كان السؤال الأول. "هل يمكن القيام به مع RDBMS؟" كان الثاني. أخيرا حصلت على الرسالة.

Answer 1

عادة ما أهرب من LDAP في أسرع وقت ممكن، لكنك استدعت للتو العبارات السحرية التي تجعل LDAP أفضل الخيار "الطبيعة الهرمية لبيانات التكوين" و "بيانات التكوين".

تم تصميم LDAP لهذا النوع (وفقط لهذا) نوع البيانات.

هناك أسباب أخرى أكثر واقعية لاختيار LDAP.

1. جميع ldaps هي نفسها. في بروتوكول الوصول وليس تنفيذ قاعدة بيانات حتى سواء كان عميلك يستخدم LDAP OpenSource أو برنامج تجاري لن يحتاج إلى التغيير.

2. جميع rdbmss مختلفة. مهما كانت RDBMS التي تختارها، ستكون هناك عميل واحد على الأقل قام بتوحيد موحدة RDBMS مختلفة غير متوافقة - إذا كنت ناجحا بشكل معقول، فسوف ينتهي الأمر بالحفاظ على شوكة على الأقل MySQL و Postgress و SQLServer و Oracle و DB2 و Sybase.

إذا كان عميلك / مدربك يتخلط أنه ليس من قبل Bulletroof / Performant / Transactional مثل Oracle / DB2 أن يكون لدى العميل خيار استخدام تطبيق LDAP Oracle أو DB2.

الجانب السلبي الحقيقي الوحيد هو عدم وجود تجربة LDAP هناك. معظم المطورين تجربة LDAPS فقط مع مخطط أمان المستخدم الافتراضي الذي يأتي مع J2EE.

مخطط LDAP هي قواعد بيانات وسوف تتطلب قاعدة بيانات مثل إيداع وإجراءات التحكم في التحكم!

2. قائمة الاغراض

Answer 2

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

إذا كنت تتطلع إلى دمج المصادقة المتكاملة في نهاية المطاف عبر منصات متعددة (Windows / Linux / إلخ)، فإن LDAP هو الطريق للذهاب. لا تفعل معظم مصادقة LDAP LDAP لخادم OS وسطح المكتبي فقط، ولكن يمكن بسهولة تجميع LDAP أو مزامنة عبر مواقع متعددة.

من الممكن تماما أن ينتهي بك الأمر إلى حل هجين. يمكن أن تقيم غالبية التحكم في تغيير التغيير DB (CCDB) في RDBMS، ولكن يمكن توصيل المصادقة بمجموعة LDAP. يمكن أن إدارة الأمام الموحدة إدارة المعلومات في كليهما. تجنب حفظ كلمات مرور الحساب في CCDB الخاص بك، لأسباب أمنية استخدم LDAP بدلا من ذلك.

سواء كنت تذهب مع RDBMS أو LDAP، فمن المحتمل أن تكتب البرامج النصية المجمع أو التطبيقات أو الواجهة الأمامية المستندة إلى الويب لإضافة / تحديث المعلومات في CCDB. يساعد هذا في تقليل منحنى التعلم للموظفين الجدد وكلا يبسطين وتحكم في التحديثات إلى قاعدة بيانات التحكم في التغيير.

لا تقلل من مخاطر الإشارة إلى موظف جديدا في RAW RDBMS وآمل في الأفضل. يمكن أن تكون مخططات CCDBS الشاملة معقدة للغاية، بغض النظر عن التكنولوجيا التي تختارها طرازها.

Answer 3

سأذهب مع نهج RDBMS للأسباب التالية:

1. يمكنك تعديل وتوسيع هيكلها بسهولة.
2. إذا كانت الشبكة الخاصة بك أنت نمذجة هي أي شيء مثل لي، فسيكون ذلك كارثة لمحاولة نموذجه بطريقة هرمية. (ليس أساسا.). على سبيل المثال قواعد جدار الحماية، خادم الوصول إلى الخوادم الأخرى، الشبكة الفرعية الخ
3. إنه سهل الإبلاغ عنها.
4. من الأسهل العثور على المطورين المهرة في SQL ثم في LDAP.
5. من السهل نسبيا تلبية الحالات الخاصة، هل يمكن القيام بذلك بسهولة في LDAP؟

بعد أن قال ذلك، أنا أكثر دراية نهج RDBMS، لذلك أنا متحيز.

Answer 4

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

Answer 5

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

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

Answer 6

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

يمكنك استخدام SQLite إذا كنت ترغب في الذهاب إلى مسار DRBMS، لكنني سأذهب بالفعل لخيار ثالث - قواعد بيانات XML. كما كنت تستخدم بالفعل XML، يجب أن يكون التبديل سهل الانتقال إلى شيء مثل بيركلي ديسم XML للتخزين. يمكنك أيضا التحقق من ويكيبيديا ل قائمة بدائل أخرى

(وإخلاء المسؤولية - لم أستخدم أي قواعد بيانات XML مطلقا؛ لقد استخدمت OpenLDAP و IDS و EDIRECTION على جانب LDAP و Oracle و SQL Server و MySQL و PostgresQL و SQLite وغيرها على جانب RDBMS)