перечисления в базе данных SQL Server - PullRequest
14 голосов
/ 09 января 2012

Есть ли лучший или более простой способ сохранить перечисления (перечисления, доступные на языках программирования, таких как C #) в базе данных SQL Server, кроме простого создания таблицы поиска (с Id, кодом и именем в качестве столбцов) для каждого из них (особенно когда в каждой из этих таблиц очень мало строк)? Я нашел статью , в которой предлагается создать только одну таблицу поиска для всех перечислений, и некоторые люди в комментариях критикуют этот подход, говоря, что он нарушает целостность ссылочных данных. если вообще перечисление используется только одной таблицей, рекомендуется ли использовать некоторые предопределенные коды, а затем добавить для них ограничение (возможно, используются расширенные свойства)?

Ответы [ 3 ]

19 голосов
/ 09 января 2012
  1. Лично мне нравится определять одну таблицу поиска для каждого перечисления, потому что это тоже своего рода документация. Если кто-то хочет знать, что означает идентификатор, он легко найдет его в таблице. Поиск этой информации в ограничении столбца не очевиден.

  2. Также гораздо проще добавлять новые значения в таблицу, чем в ограничение.

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

  4. При необходимости вы можете добавить дополнительную информацию в отдельные таблицы поиска, помимо идентификатора и текста (например, комментарий, столбец сортировки, какой-либо флаг и т. Д.).

  5. И, как вы сказали, это лучше для ссылочной целостности

Тем не менее, если вы используете o / r-mapper с подходом «сначала код», использование перечислений, предоставляемых языком программирования, кажется вполне естественным. Это потому, что вы разрабатываете не базу данных, а объектную модель. O / r-mapper создает базу данных автоматически для вас.

0 голосов
/ 09 января 2012

Использование одной и той же таблицы для нескольких поисков может вернуться, чтобы преследовать вас. Одним из примеров является создание индексированного представления. Это может помочь с производительностью, если у вас есть несколько полей, в которых вы хотите отобразить значение поиска, но SQL Server (по крайней мере, 2005) не позволит вам ссылаться на одну и ту же таблицу более одного раза (если это будет исправлено, я бы действительно хотелось бы знать, как это сделать, потому что я действительно мог бы использовать его в текущем приложении с одной таблицей поиска.).

Для одного из ваших поисков может потребоваться дополнительное поле, и при использовании одной таблицы у вас будет много ненужных нулей. Индексирование может быть более гибким с отдельными таблицами. Что, если для одного конкретного типа поиска требуется новое поле? SQL Server хорошо справится с ограничением, но при добавлении в ту же таблицу потребуется немного больше сложности.

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

0 голосов
/ 09 января 2012

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

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

«Одна таблица истинного поиска» не даст вам никаких преимуществ.

Редактировать: Если вам нужно динамически извлекать значения перечисления (например, для раскрывающегося списка) или вам нужно выяснить, какие значения разрешены, тогда вам лучше использовать таблицы поиска.

...