ASP.NET MVC 2 View Model DDL списки: где хранить выбор, жесткий код в представлении или хранить в базе данных?

Question

В настоящее время у нас есть таблица «Lookup», которая содержит набор возможных вариантов для таких вещей, как выпадающий список. Если бы это был список сокращений состояний, LookupID представлял бы набор, а LookupItemID представлял бы отдельное состояние.

customerID   int     PK
lookupID     int     PK
lookupItemID int     PK
lookupValue  string

Это адрес хранения параметров DDL, но не того, как они должны отображаться в представлении. Кажется безумным настраивать ссылочную целостность между каждой таблицей, у которой есть список опций. Например, у нас есть «Список покупателей», в котором есть список Имен покупателей, используемый на экране «Продукт» (некоторые покупатели обрабатывают определенные продукты)

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

Есть предложения?

Answer 1

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

Если параметры в любом из DropDowns представляют собой очень заданный список, такой как Active / Inactive, я также видел использование Enum на стороне кода, используемой в логике, так как User.status == Status.Active дружелюбнее, чем User .status == 5 ....

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