проектирование базы данных - наилучшая практика - одна таблица для параметров раскрывающегося списка веб-формы или отдельная таблица для каждого варианта раскрывающегося списка

Question

Я смотрю на лучший подход практики здесь. У меня есть веб-страница с несколькими опциями. Выпадающие списки не связаны, они для разного. значения (местоположение, строительные нормы и т. д.). В базе данных сейчас есть таблица для каждого набора параметров (например, таблица для строительных норм, таблица для местоположений и т. Д.). Мне интересно, могу ли я просто объединить их все в таблицу (называемую listOptions), а затем просто запросить эту таблицу.

Location Table
LocationID (int)
LocatValue (nvarchar(25))
LocatDescription (nvarchar(25))

BuildingCode Table
BCID (int)
BCValue (nvarchar(25))
BCDescription (nvarchar(25))

Вместо вышесказанного, есть ли причина, по которой я не могу этого сделать?

ListOptions Table
ID (int)
listValue (nvarchar(25))
listDescription (nvarchar(25))
groupID (int) //where groupid corresponds to Location, Building Code, etc

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

Answer 1

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

Answer 2

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

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

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

У нас было примерно 600 веб-сайтов на одном и том же сервере, и все они использовали один и тот же экземпляр SQL Server (отдельные базы данных), и общее количество операций ввода-вывода для нашей серверной базы данных было резко сокращено.

Edit:

Мы просто создали SSI, который выглядел следующим образом ...

Blue
Red
Зеленый

Answer 3

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

Answer 4

Если вы планируете использовать значения позже в некоторых ссылочных FKeys - лучше использовать отдельные таблицы.

Но зачем вам таблица «все в одном»?Какую проблему это решает?

Answer 5

Лучшая практика зависит от ваших требований.Часто ли значения местоположения и здания меняются?Откуда берутся ценности?Импортированы ли они из внешних данных?Другие таблицы ссылаются на уникальную таблицу (так что мне нужен ключ с двумя полями для предварительного объединения таблиц)?Например, я использую уникальную таблицу с данными неоднородности для констант или значений конфигурации.Но если данные часто меняются или импортируются из внешнего источника, я предпочитаю использовать отдельные таблицы.

Answer 6

С одной таблицей было бы легко добавлять новые группы в пользу создания новых таблиц, но для наилучшей практики у вас также должна быть таблица групп, чтобы вы могли называть эти группы в БД для будущего обслуживания