Подтвердить что ты не робот

Как создать таблицу параметров приложения в базе данных

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

  • Сохраните настройки в столбце и одну строку для ключа - что-то вроде этого:

enter image description here

  1. Сохраняйте настройки только в двух строках - примерно так:

enter image description here

Какой из двух вариантов более подходит для хранения настроек приложения?

С наилучшими пожеланиями

4b9b3361

Ответ 1

Используйте второй метод. Очевидно, что это гораздо более масштабируемо. Вам больше не нужно добавлять дополнительные столбцы, если вам нужно добавить дополнительные параметры.

Я бы только защищал первый метод, если параметры очень ограниченные и фиксированные, и все имеют разные типы данных. Это область, где эти два существенно отличаются друг от друга - если у вас есть большое количество числовых и символьных столбцов, у вас нет выбора со вторым вариантом, но для сохранения их всех как VARCHAR. Однако для таблицы настроек, которая будет иметь очень ограниченное количество строк и не будет подвержена множеству INSERT и UPDATE, это, вероятно, не является большой проблемой.

Вы не захотите использовать второй метод для обычной таблицы (не сохраняя в основном статические параметры приложения), который должен быть высокодоступным или использоваться для вычислений, например, где вам постоянно нужно будет вводить значения типа литья, чтобы манипулировать их.

Для статических данных, которые редко доступны или изменены, второй метод работает хорошо.

Ответ 2

Это зависит от того, как часто эти значения меняются и как изменяются типы:

Если, например, у вас есть конечное количество настроек для многих разных типов, то горизонтальная компоновка лучше, потому что вы можете указать каждый тип. Но каждый раз, когда вы хотите добавить новый, вы сможете изменить таблицу.

И наоборот, если у вас много разных типов, и у людей есть много разных настроек, и, возможно, даже вы знаете, что новые будут продолжать появляться в будущем, тогда второй листинг будет лучше. Проблема в том, что вы будете зацикливаться на varchar (nnn) для каждого значения, поэтому db не сможет помочь вам с типизацией.