перечисления в базе данных SQL Server

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

14
database-design normalization sql sql-server

3 ответов

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

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

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

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

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

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

19

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

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

"одна истинная таблица поиска" не даст вам никаких преимуществ.

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

0

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

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

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

0