Уникальные, но все же простые идентификаторы базы данных в SQL Server

Во-первых, я знаю этот вопрос, и предложение (с использованием GUID) не применимо в моей ситуации.

Я хочу простые UID, чтобы мои пользователи могли легко передавать эту информацию по телефону:

Привет, У меня проблема с заказом 1 584

в отличие от

привет, у меня проблема с заказом 4daz33-d4gerz384867-8234878-14

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

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

Моя нынешняя идея - использовать столбцы идентификаторов с разными семенами 1, 2, 3 и т.д. и значение приращения 100.

Это вызывает несколько вопросов:

Что делать, если в итоге я получу более 100 типов объектов? что я мог бы использовать 1000 или 10000, но что-то, что плохо масштабируется "запахи"
Возможно ли, что семя "потеряно" (во время репликации, проблемы с базой данных и т.д.?)
В общем, есть ли другие проблемы, о которых я должен знать?
Можно ли использовать не целое число (в настоящее время я использую bigints) как столбцы идентификаторов, чтобы я мог префикс идентификатора с чем-то, представляющим тип объекта? (например, столбца varchar)
было бы хорошей идеей для пользователя "главная таблица", содержащая только столбец идентификатора, и, возможно, тип объекта, чтобы я мог просто вставлять в него строку, когда нужна новая идея. Я чувствую, что это может быть немного переборщить, и я боюсь, что это уложит все мои запросы на вставку. Плюс тот факт, что я не смогу определить тип объекта, не глядя на базу данных
Есть ли другие умные способы решения моей проблемы?

Ответ 1

Почему бы не использовать идентификаторы во всех таблицах, но в любое время, когда вы представляете их пользователю, просто нажмите на один char для типа? например O1234 - заказ, D123213 - доставка и т.д.? Таким образом, вам не нужно разрабатывать какую-то сумасшедшую схему...

Ответ 2

Обращайтесь к нему в пользовательском интерфейсе - добавьте букву (или буквы) префикса в идентификационный номер, сообщая об этом пользователям. Таким образом, o472 был бы порядком, b531 - это счет и т.д. Людям достаточно удобно смешивать буквы и цифры, когда они дают "цифры" по телефону и точнее, чем с прямыми цифрами.

Ответ 3

Вы можете использовать столбец автоинкремента для создания уникального идентификатора. Затем вычисленный столбец, который принимает значение этого столбца и добавляет его с фиксированным идентификатором, который отражает тип объекта, например OR1542 и DL1542, будет представлять собой порядок # 1542 и доставку # 1542 соответственно. Ваш префикс может быть расширен настолько, насколько вам хочется, и формат может быть организован, чтобы помочь разграничить элементы с тем же значением автоинкремента, например OR011542 и DL021542, причем префиксы являются OR01 и DL02.

Ответ 4

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

Каждая ваша фактическая таблица Order, Delivery... будет иметь ссылку FK обратно в таблицу Entity. Это даст вам уникальный столбец идентификатора

Использование семян на мой взгляд - плохая идея, и это может привести к проблемам.

Изменить

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

После того, как я написал этот ответ, я подумал, но больше о том, почему вы это делаете, и я пришел к тому же выводу, что и Мэтт.

Ответ 5

Проект преднамеренного программирования MS имел систему GUID-to-word, которая давала объявляемые имена из произвольного идентификатора

Ответ 6

Почему не просто базовое представление bigint? http://en.wikipedia.org/wiki/Base_36

Ответ 7

Мы столкнулись с аналогичной проблемой в проекте. Мы решили это, сначала создав простую таблицу, которая имеет только одну строку: BIGINT устанавливается как идентификатор автоинкремента. И мы создали sproc, который вставляет новую строку в эту таблицу, используя значения по умолчанию и внутри транзакции. Затем он сохраняет SCOPE_IDENTITY в переменной, отбрасывает транзакцию и затем возвращает сохраненный SCOPE_IDENTITY.

Это дает нам уникальный идентификатор внутри базы данных, не заполняя таблицу.

Если вы хотите знать, к какому объекту относится идентификатор, я бы потерял откат транзакции и сохранил тип объекта вместе с идентификатором. Таким образом, выясните, к какому объекту относится Ид - это только один выбор (или внутреннее соединение).

Ответ 8

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

В моей базе данных у меня есть таблица идентификаторов с полем счетчика. Это высокая часть. В моем приложении у меня есть счетчик, который идет от 0 до 99. Это низкая часть. Сгенерированный ключ 100 * высокий + низкий.

Чтобы получить ключ, я делаю следующее

initially high = -1
initially low = 0

method GetNewKey()
begin
  if high = -1 then
    high = GetNewHighFromDatabase

  newkey = 100 * high + low.
  Inc low
  If low = 100 then
    low = 0
    high = -1

  return newKey
end

Реальный код более сложный с замками и т.д., но это общий смысл.

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

Этот алгоритм дает простые клавиши, избегая при этом большинства ударов db каждый раз, когда каждый раз просматривает новый ключ. В тестировании я обнаружил, что он имеет схожую производительность с конвейерами и значительно более высокую производительность, чем каждый раз при использовании ключа auto inc.

Ответ 9

Вы можете создать таблицу master UniqueObject с вашей личностью и подтипом. Субтитры (Заказы, Пользователи и т.д.) Будут иметь FK для UniqueObject. INSTEAD OF INSERT триггеры должны держать боль до минимума.

Ответ 10

Может быть, вариант itemType-year-week-OrderNumberThisWeek?

o2009-22-93402

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

Ответ 11

У меня была аналогичная ситуация с проектом.

Мое решение: по умолчанию пользователи видят только первые 7 символов GUID.

Это достаточно случайное, что столкновения крайне маловероятны (1 из 268 миллионов), и он эффективен для разговора и набора текста.

Внутри, конечно, я использую весь GUID.