Лучший способ хранения данных настроек сайта в таблице базы данных?

Два способа работает нормально. Я бы сказал, что если вы хотите управлять этими настройками в административной панели, лучше настроить один параметр по столбцу, потому что вы можете добавлять новые настройки на лету с помощью простого INSERT запрос от вашего администратора. Что лучше (более безопасно), чем ALTER TABLE запрос.

Прежде всего, я хотел бы рассмотреть еще одну вещь, файл конфигурации …

Тогда вы должны спросить себя, что вам нужно для вашего проекта …

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

Большим преимуществом опций баз данных над файлом конфигурации является масштабируемость: если у вас есть много приложений / сайтов, запрашивающих эти конфигурации, тогда перейдите к базе данных, поскольку это позволит вам не копировать несколько раз один и тот же файл конфигурации со всеми проблемами управления версиями и изменениями. файла на всех этих разных «сайтах»

В противном случае я бы придерживался файла конфигурации, так как доступ к приложению быстрее, и файл все еще может быть доступен в случае сбоя сервера sql, и в этом случае некоторая конфигурация все еще может появиться, файл конфигурации также может быть включен вашим программным обеспечением контроля версий. Также по какой-то причине безопасности представьте, что ваша БД используется многими программами …

Затем, если вы придерживаетесь базы данных, я бы порекомендовал одну строку, одну метку, один конфиг, я считаю, что управлять записями проще, чем структурой таблиц, особенно с течением времени и в ходе эволюции вашего программного обеспечения. Если другие разработчики присоединятся к вашему проекту, ваша структура таблиц может быстро стать большой беспорядок:]

Последний аргумент — безопасность … хорошей практикой является установка «пользователя БД» из программного обеспечения для пользователя, у которого нет прав на изменение структуры БД, только право доступа / удаления записей для удаления;)

Это будет зависеть от технологии, которую вы используете. Например, в проекте PHP Symfony настройки в основном хранятся в плоских файлах (Json, xml …).

Я работал над многими большими веб-приложениями для клиентов. Таблица ключ / значение обычно используется для хранения простых настроек. Если вам нужно хранить более одного значения, вы должны их сериализовать, так что это немного сложно.

Имейте в виду, что для шифрования конфиденциальных данных, таких как пароли (Sha256 + соль).

Лучший способ — создать две таблицы.
Таблица для сохранения настроек как ключ / значение:

CREATE TABLE Settings (
Id INT NOT NULL PRIMARY KEY,
Key NOT NULL NVARCHAR,
Value NULL NVARCHAR
EnvId INT NOT NULL
);

Тогда вам нужна таблица среды.

CREATE TABLE Environment  (
Id INT NOT NULL PRIMARY KEY,
Key NOT NULL NVARCHAR,
);

Не забывайте об ограничении внешнего ключа.

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

Таким образом, вы можете работать со многими средами (dev, test, production, ….), вам просто нужно активировать одну среду. Например, вы можете настроить не отправлять электронную почту в env разработки, а отправлять ее в рабочий env.

Таким образом, вы выполняете объединение, чтобы получить настройки для указанной среды. Вы можете добавить логическое значение, чтобы легко переключаться между средами.

Если вы используете файл (он не требует подключения к базе данных), вы можете получить что-то вроде этого (Json):

Env:
Dev:
Email: ~
Prod:
Email: [email protected]