Проектирование баз данных - трудно кодированный идентификатор строки

Не делайте этого.;-)

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

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

Я часто играл с идеей генерировать или 'исходный код' Класс Enum от Таблиц базы данных или заполнить Таблицы базы данных информацией о Классе Enum в сборке/времени развертывания, но я 'никогда не находил время для него'.

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

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

я соглашаюсь с Ken G - наличие перечислимых значений соответствует идентификаторам строки, только имеет смысл для справочных таблиц со статическим (неизменным) содержанием

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

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

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

Так или иначе Вы - проблема, прибывает из того, что Вы сохраняете/загружаете от ЦЕЛОГО ЧИСЛА позади текста ПЕРЕЧИСЛЕНИЯ. Решение, которое поможет здесь, состояло бы в том, чтобы сделать поиски/сохранять/и т.д. от ТЕКСТОВОГО значения перечисления

Этот код VB переводит строку назад в ПЕРЕЧИСЛЕНИЕ, и это должно быть достаточно легко к порту к C#:

[Enum].Parse(System.Type, Value)

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

Но если столбец первичного ключа является целым числом со знаком, можно использовать отрицательные величины для статических строк. Идентификатор-1 означает '-НИ ОДИН -', идентификатор-2 означает '-ОСОБЕННЫЙ -' или что бы то ни было. Если Вы нуждаетесь в большем количестве статических строк, совершенствуетесь в отрицательном направлении.

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

ROWIDs никогда не должен храниться, потому что они могут измениться. При перемещении одной из этих таблиц к новой табличной области, все сохраненные ROWIDs стали бы недопустимыми (это верно в Oracle, так или иначе).

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

Не судя рациональность Вашего плана. И другим людям DBA всегда нравится говорить, "не делают этого". как будто Вы спросили, необходимо ли сделать это или нет, и даже если Вы не попросили, чтобы, как Вы имели выбор не сделать это.

Я предположу, что Вы задали свой вопрос по причине и что у Вас нет выбора не сделать это.

У меня есть друг, который думает, что последовательности Oracle являются болью и что поля автонумерации настолько легче. Они не так "легки", но они намного более гибки. К этой точке Вы не заявили свою платформу, таким образом, никакая модификация-1.

В Oracle Вы создаете последовательности для заполнения полей автонумерации. Последовательности абсолютно независимы от таблиц. Можно использовать одну последовательность в нескольких таблицах, можно использовать несколько последовательностей в одной таблице. Если бы я должен был решить Вашу ситуацию, то я создал бы 2 тех последовательностей, которые запускаются в 1 и ступают 2 (для администраторских данных) и тот, который запускается в 2 и ступает 2 (для пользовательских данных). Я изменился бы, моя процедура вставки, чтобы иметь опциональный параметр для администратора вставляет для получения по запросу корректной последовательности. у Вас никогда не будет коллизий Ваших данных и Ваших пользовательских данных. Существует побочный эффект способности различать два на основе четности идентификатора. Оборотная сторона - то, что существует жесткий предел.

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

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

То, что Вы могли сделать, является запуском Ваша последовательность в 1 001. Любые значения между 1 и 1,000 являются "встроенными" значениями. Конечно, 1000 магическое число здесь, но в моем случае у меня только было 5 встроенных значений, таким образом, это казалось довольно безопасным.

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