Мне нужно больше информации о реализации перечислений с SQL Server. SQL Сервер не имеет прямой поддержки перечислений, а C# не имеет перечислений строк. Для сервера SQL основными параметрами являются проверка ограничений и справочные таблицы. Для перечислений, которые не меняются (например, On, Off), проверочные ограничения работают. Для перечислений, в которые будут добавлены новые элементы (например, категория, тип), таблицы поиска не требуют изменений в определении базы данных. Новые значения могут быть легко добавлены в таблицу поиска. Данные таблицы поиска также могут служить для заполнения выпадающих списков во внешнем интерфейсе. Кроме того, таблицы поиска могут содержать порядок сортировки, если это необходимо.
В большинстве рекомендаций рекомендуется использовать поле tinyint в качестве первичного и внешнего ключа для повышения эффективности и упрощения сопоставления с перечислениями C#. Главный недостаток состоит в том, что без присоединения каждого перечисления к его таблице поиска записи не читаются человеком. Я предпочитаю естественные ключи, если это возможно. Их легче читать и понимать, и они менее подвержены ошибкам. Наша база данных содержит множество таблиц с множеством перечислений. Поэтому мне неудобно использовать много целочисленных ключей для перечислений, поскольку 1,2,3, ... всегда будут иметь разное значение.
Я вижу два решения:
Используйте поле char (1) в качестве ключа. Код символа может использоваться в C# как значение перечисления. Проблема в том, что иногда члены перечисления могут начинаться с одной и той же буквы, и необходимо использовать другую неинтуитивную букву, что снижает удобочитаемость. Это все равно будет лучше, чем числа.
Используйте поле varchar соответствующей длины и введите полное значение (например, AddressType: 'Home', 'Work', 'Shipping'). Это обеспечит оптимальную читаемость. Таблица поиска по-прежнему обеспечивает целостность. В C# целочисленные значения перечислений используются только для внутреннего использования. Для операций с базой данных можно использовать имя перечисления. Недостаток - увеличенное место в базе. Учитывая количество других данных, лишними символами на запись пренебречь. Соединение будет стоить дороже, но оно нужно только для вставок или обновлений для проверки целостности. Таблицы поиска по-прежнему могут передавать значения combobox.
Главный недостаток обоих решений заключается в том, что если изменение перечисления потребует изменения ключа для удобства чтения, все затронутые записи должны быть изменены. Поскольку перечисления обычно не меняются, я не вижу в этом практической проблемы. Если перечисления существенно меняются из-за обновления приложения, обычно в любом случае есть что обновить.
В нашем случае я предпочитаю отказаться от простого обновления для удобства чтения. Что я упускаю из виду при использовании char или varchar в качестве ключа? Если нет, есть ли еще что-нибудь, что делает вариант 1 или 2 лучшим выбором?
Спасибо за любую помощь.