Дизайн базы данных - жестко заданный идентификатор строки

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

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

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

Я часто играл с идеей создания либо класса Enum «исходного кода» из таблиц БД, либо заполнения таблиц БД информацией о классе Enum во время сборки / развертывания, но я так и не «дошел до этого».

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

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

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

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

В любом случае, ваша проблема возникает из-за того, что вы сохраняете / загружаете из INTEGER за текстом ENUM. Решением, которое поможет здесь, было бы выполнять поиск / сохранение / и т. д. Из значения TEXT перечисления

Этот код VB переводит строку обратно в ENUM, и его должно быть достаточно легко перенести на C#:

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

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

Если вам нужно пометить определенные специальные записи, поместите какое-то поле «флаг», которое указывает на это, и вместо этого запросите этот флаг.

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

Но если столбец первичного ключа является целым числом со знаком, вы можете использовать отрицательные значения для своих статических строк. ID -1 означает «-NONE-», ID -2 означает «-SPECIAL-» или что-то еще. Если вам нужно больше статичных строк, продвигайтесь в отрицательном направлении.

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

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

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

Не судить о рациональности вашего плана. Администраторы баз данных и другие люди всегда любят говорить: " не делай этого », как если бы вы спросили, следует ли вам это делать или нет, и даже если вы этого не просили, как будто у вас есть выбор не делать этого.

Я предполагаю, что вы задали свой вопрос по какой-то причине и что у вас нет выбора, чтобы не делать этого.

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

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

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

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

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

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

Я согласен со Стивеном В. в том, что хорошее решение - использовать строку name элемента ENUM. Я постоянно использую этот метод в .Net, и он прост в использовании.

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

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

PK_ID | CODE | Other Data и др.

Здесь значение поля кода на самом деле является вашим именем Enum. Это код, который не нужно менять. Вы должны установить между собой и своей командой правило, согласно которому они НЕ МЕНЯТЬСЯ, но если кому-то нужно его изменить, убедитесь, что оно отражено на обеих платформах.

Использование .Net для работы с Enum (в этом примере называется SortDirection):

' Get the string name of an enum
[Enum].GetName(GetType(SortDirection), SortDirection.Ascending)

' Get the enum value from its string name
CType([Enum].Parse(GetType(SortDirection), "Ascending"), SortDirection)

Это не идеальное решение, но оно мне хорошо послужило; Я слишком много раз был смущен и раздражен жестко закодированными идентификаторами, чтобы не оценить лучшее из этих двух зол. Надеюсь, это поможет!