خيارات مختلفة حول كيفية الاحتفاظ بتفضيلات موقع الويب؟

Question

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

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

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

فيما يلي الأفكار القليلة التي توصلت إليها من خلال البحث قليلاً على هذا الموقع و/أو Google ، لكنني لست متأكدًا جدًا من إيجابياتهم وسلبياتهم:

• احمل بشكل أساسي جميع التفضيلات في جدول كما ذكرت أعلاه ، شيء أود تجنبه.
• احتفظ بكل هذه التفضيلات "الفردية" في ملف XML الذي أقوم بتعديله عند تغيير إعداداتها.
• احصل على جدول يسمى التفضيلات مع columsn التالية: معرف ، تفضيل ، القيمة. في كل مرة كان لديّ تفضيل جديد ، سأضيفه فقط ، أو تعديله ، أو إزالته (لا أحب هذا الخيار لأنني أشعر أنه يتعين عليّ أن يرمز الكثير من القيم ... على الأقل من الطريق أرى التنفيذ)

أنا نوع من الميل نحو فكرة XML ولكني أود الحصول على بعض التعليقات من المجتمع الجيد هنا في Stackoverflow :) ربما يكون استخدام XML فكرة مروعة لسبب ما أغفلته تمامًا أو هناك -لماذا لا أنت لا تحل عن هذا الحل. شكرا على أي مدخلات!

Answer 1

يعمل مسار XML بشكل جيد بمعنى أنه يسمح بسهولة بإضافة سمات جديدة ويسمح بتجميع سمات. الجانب السلبي هو أنه من المستحيل ترحيل أو تحديث بيانات التفضيل باستخدام SQL. يجب أن يتم برمجيا. لا يمكنك أيضًا الاستعلام عن تفضيلات السمات الفردية في حالة ظهور الحاجة.

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

Answer 2

أود أن أقول استخدام جدول قاعدة بيانات واحد إذا كان لديك ذلك بالفعل ، وقسم أسماء الإعدادات إلى فئات معقولة:

mail_service:recipients
mail_service:sender
mail_service:smtp:hostname
mail_service:smtp:username
mail_service:smtp:password

بخلاف ذلك ، أنا أفضل كثيرا يامل إلى XML من أجل قابلية القراءة. إنه مثل XML ولكن بدون كل الفوضى.

 mail_service:
     recipients:
       - recipient1@domain.com
       - recipient2@domain.com
       - recipient3@domain.com
       - recipient4@domain.com

  visuals:
    header:
      text_color: #BBCCDD
      background_color: #FFFFFF

ال فئة Symfony Yaml هي مكتبة مستقلة جيدة لتحليل هذا الملف في مجموعة PHP.

يمكنك أيضا استخدام ملف PHP بسيط.

$settings = array(
 "mail_service:recipients" => " .... ",
 "mail_service:sender" => " .... ",    
 "mail_service:smtp:hostname" => " .... ",
 "mail_service:smtp:username" => " .... ",
 "mail_service:smtp:password" => " .... ");

Answer 3

سأذهب مع ملف XML (على الرغم من أنه لا يحتاج إلى أن يكون XML-إذا كان Java ، فسأستخدم ملف خصائص حتى وجدت سببًا لعدم ذلك) أو جدول مفتاح واحد/قيمة (حقل المعرف لا كسبك كثيرًا ما لم يكن مفتاحًا خارجيًا للتمييز بين المنشآت المختلفة).

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

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