Различные варианты того, как сохранить настройки сайта? - PullRequest
Новая
       58

Различные варианты того, как сохранить настройки сайта?

0 голосов
/ 05 июля 2010

Я нахожусь в процессе обновления нашей CMS, и я столкнулся с ситуацией, в которой я не знаю, какое решение принять.По сути, каждый из наших клиентов размещает контент своего веб-сайта в своей собственной базе данных.Это включает в себя контент, опросы, поисковые слова, используемые посетителями, структуру меню и т. Д.

Большая часть контента на сайтах наших клиентов является динамичной, и они могут изменять их через CMS.Все эти данные сохраняются в реляционной базе данных, которую я разработал, но я работаю в нескольких ситуациях, когда хранение этих предпочтений в таблице было бы излишним.

Например, CMS позволяет им отправлять электронные письмав список получателей.Они могут использовать наш сервер или установить собственный SMTP-сервер.Однако в этом случае было бы немного излишним создавать таблицу со столбцом для «mailService» и содержать в ней определенные значения, поскольку таблица будет содержать только одну строку.

Вот несколько идей, которые япридумали, немного поискав на этом сайте и / или в гугле, но я не слишком уверена, каковы их плюсы и минусы:

  • В основном все предпочтения содержатся в таблице, как я упоминалвыше, что я хотел бы избежать.
  • Храните все эти «одиночные» настройки в XML-файле, который я бы изменил, когда они изменят свои настройки.следующий столбец: id, preferenceName, значение.Каждый раз, когда у меня появляется новое предпочтение, я просто добавляю, изменяю или удаляю его (мне не нравится эта опция, потому что я чувствую, что мне придется жестко задавать слишком много значений ... по крайней мере, такЯ вижу реализацию)

Я склоняюсь к идее XML, но я хотел бы получить отзывы от хорошего сообщества здесь, в Stackoverflow :) Возможно, использование XML было быУжасная идея по причине, которую я полностью упустил из виду, или есть решение «ты тупой, почему не сделал, просто сделай это».Спасибо за любой вклад!

Ответы [ 3 ]

2 голосов
/ 05 июля 2010

Я бы сказал, используйте одну таблицу базы данных, если она у вас уже есть, и разделите имена настроек на разумные категории: 

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

Кроме этого, я очень предпочитаю yaml 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" => " .... ");
1 голос
/ 05 июля 2010

Я бы выбрал XML-файл (хотя он не обязательно должен быть XML - если бы это был Java, я бы использовал файл свойств, пока не нашел причину этого) или одну таблицу ключ / значение ( Поле id не принесет вам особой пользы, если только это не какой-то внешний ключ для различения различных установок).

Лично мне нравится универсальность SQL и самодостаточность. Использование базы данных не добавляет сложности, которой еще нет (вы получите тот же уровень кэширования бесплатно, например, когда вам придется увеличить свой собственный XML-кеш, если производительность является проблемой). Я бы выбрал XML только в том случае, если значения имели бы действительно сложную структуру, что сделало бы манипулирование через SQL громоздким.

Я не уверен, почему вы думаете, что вам нужно «жестко закодировать множество значений», и, в частности, почему было бы более жесткое кодирование с решением для базы данных, чем с файловым решением.

1 голос
/ 05 июля 2010

XML-маршрут работает хорошо в том смысле, что он легко позволяет добавлять новые атрибуты и позволяет группировать атрибуты.Недостатком является то, что невозможно перенести или обновить данные предпочтений с помощью SQL.Это должно быть сделано программно.Вы также не можете запросить предпочтения для отдельных атрибутов, если возникнет такая необходимость.

Скажем так, если вы поддерживаете небольшое количество предпочтений, когда нет необходимости запрашивать или обновлять их с помощью SQL, xml будет хорошо работать длявы.В противном случае было бы лучше использовать таблицу «имя-значение» в базе данных.

...