Как внедрить в NHibernate простые и удобные идентификаторы?

Question

Я разрабатываю приложение, в котором мои Order объекты должны иметь последовательное и удобное для пользователя поле Id.Я избегаю алгоритма HiLo из-за довольно больших пробелов, которые он производит (см. здесь ).Естественно, значения Guid заставят моих корпоративных пользователей пойти на бананы.Я также избегаю последовательностей Oracle из-за основных недостатков этого:

(От: Выявлены генераторы POID NHibernate )

Генераторы пост вставки, как следует из названия, присваивает идентификаторы после сохранения объекта в базе данных.Оператор выбора выполняется для базы данных.У них много недостатков, и, по моему мнению, они должны использоваться только в проектах на коричневых полях. Эти генераторы - это то, что МЫ НЕ ПРЕДЛАГАЕМ как команда NH.

> Некоторые недостатки:

• ЕдиницаРабота прерывается с использованием этих стратегий.Не имеет значения, используете ли вы FlushMode.Commit, каждое сохранение приводит к оператору вставки для БД.Рекомендуется отложить вставки до коммита, но использование генератора пост-вставок делает его фиксацией при сохранении (чего не делает UoW).
• Эти стратегии сводят на нет дозатор, вы не можете воспользоваться возможностью отправлять несколько запросов одновременно (так как он должен поступить в базу данных во время сохранения).

Любые идеи / опыт по внедрению удобных идентификаторов без существенных пробелов между ними?

Редактировать:

• Удобно для пользователя Idполя, которые мои корпоративные пользователи могут запоминать и даже обсуждать и / или иметь телефонные разговоры, говорящие о конкретном Order по его коду, например: «Я звоню, чтобы узнать, почему в заказе № 1625 было отказано».
• Id не обязательно должен быть строго без зазора, но я беспокоюсь, что мои пользователи могут запутаться, когда увидят пробелы, такие как 100, 201, 305. В моих старых проектах я в настоящее время реализуюNHibernate использует последовательности Oracle, которые иногда выдают несколько последовательностей при возникновении исключений, но при этом сохраняют для них довольно аккуратный порядок.Недостатком их является то, как они разбивают единицу работы, что приводит к дополнительным попаданиям в базу данных для каждой команды Save с Session.Flush.

или без него.

Answer 1

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

Другим вариантом может быть уточнение того, что вы подразумеваете под "дружественным к пользователю идентификатором". Это может состоять из комбинации даты / времени и определенной для клиента последовательности (или включая идентификатор клиента). Кроме того, идентификатор вашего заказа не обязательно должен быть фактическим ключом на столе. Нельзя сказать, что вы не можете использовать суррогатный ключ с отдельным «вычисляемым» столбцом, который представляет идентификатор заказа.

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