Как обращаться с перечислениями, которые на самом деле не являются перечислениями, потому что их можно изменить? - PullRequest
0 голосов
/ 11 марта 2011

Я работаю над веб-приложением для класса.По сути, это система управления проектами, похожая на разбавленную версию Bugzilla, но специально разработанная для академической среды.Одним из требований является то, что для ряда настроек (таких как тип проекта, который может быть магистерским проектом, кандидатская диссертация и т. Д.) Списки возможных значений можно настраивать.Таким образом, будет страница конфигурации или настройки, на которой вы сможете изменить значения в каждом списке, но тогда в остальной части приложения (например, при создании проекта или задачи) значения в списке будут единственными вариантами выбора.Также, если вы измените одно из значений (скажем, из магистерской работы в магистерскую диссертацию), все записи, использующие это значение, также должны измениться.Таким образом, все проекты, помеченные как магистерская работа, теперь будут отмечены как магистерская работа.

Я использую HSQLDB для хранения данных, а приложение написано полностью на Java (JDBC, JavaServlets, JSP).

Мне трудно понять, как справиться с этим требованием с точки зрения дизайна.Во-первых, как мне сохранить эти списки в базе данных?Будет ли каждый список своей таблицей?Кажется неправильным иметь каждый список в виде столбца в одной таблице (не будет ли это нарушать правила нормализации?).Я не очень знаком с дизайном базы данных, но поиск в Google не нашел хорошего решения для этого.

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

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

Ответы [ 3 ]

2 голосов
/ 11 марта 2011

Каждое «перечисление» должно храниться в отдельной таблице, чтобы вы могли иметь внешние ключи к этой таблице.

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

2 голосов
/ 11 марта 2011

это стандартная нормализация.

создать таблицу списка

mylist
---------
option_id 
option_name

затем свяжите его с другой таблицей, если необходимо

my_other_table
--------------
attributes...
option_id

пользовательский интерфейс для установки значений для запросов my_other_table в mylist для значений, которые должны входить в поле со списком или любой другой компонент пользовательского интерфейса, который вы выбираете.

0 голосов
/ 11 марта 2011

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

...