Синхронизация таблиц и перечислений ссылочной целостности

Я время от времени задумываюсь над этим вопросом, поэтому решил спросить вас, ребята.

Допустим, у меня есть таблица базы данных, которая выглядит следующим образом: 

Table: Visibility
Id   Value
--   -----
 0   Visible
 1   Invisible
 2   Collapsed

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

В моем переднем конце у меня есть несколько вариантов.

  1. я мог бы запросить эту таблицу и сохранить ее в, скажем, a Dictionary<string, int> или a Dictionary<int, string>.

  2. Я мог бы написать перечисление вручную и просто вручную отредактировать значения в том редком случае, если в таблице есть изменения. Например,

    public enum Visiblity { Visible, Invisible, Collapsed }

  3. Что-то еще????

Что бы вы посоветовали и почему?

Спасибо.

6 5
c# enums database referential-integrity

6 ответов:

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

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

3

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

1

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

1

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

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

1

Если у вас есть какая-либо бизнес-логика, основанная на перечислении, ваш основной вариант-синхронизировать ее вручную. Если эти строки также являются внешними ключами для другой таблицы (допустим, у вас есть таблица поиска статусов), вы должны сделать тип ID обычным int с уникальным индексом вместо Identity, чтобы вы могли легко поддерживать пары ID/Value одинаковыми, если у вас есть базы данных в разных средах.

0

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

0