Идентификатор синхронизации по нескольким объектам

Question

У меня есть приложение, которое имеет объекты, которые могут быть: CustomerType1, CustomerType2 и CustomerType3.

Все три объекта CustomerType могут иметь совершенно иную информацию, но все они имеют поле CustomerID, которое является целым числом.

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

Например, создание следующего приведет к следующему CustomerID

CustomerType1 - 1

CustomerType1 - 2

CustomerType1 - 3

CustomerType2 - 4

CustomerType1 - 5

CustomerType3 - 6

CustomerType1 - 7

Что такое лучший способ приблизиться к этому?

Answer 1

2 возможных подходов:

1. Используйте одну таблицу для всех ваших типов клиентов с полем «дискриминатор» для отслеживания каждого типа клиента, и включают в себя CustomerID в качестве своей идентичности.
2. Используйте внешнюю таблицу для управления созданием CustomerID в качестве поля идентификации.

Первый подход имеет то преимущество, что непосредственную поддержку в Entity Framework для, как описано в следующем руководстве:

http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-inheritance-with-the-entity-framework-in-an-asp-net-mvc-application

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

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

Answer 2

Ваш подход похож на тот же тип сущности в сетевых базах данных с уникальными идентификаторами.

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

Некоторые базы данных хранят это значение как строку, а не целое число.

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

Решение 1

Если ваша база данных поддерживает U.I.D. или O.I.D. или Уникальные идентификаторы, которые генерируются автоматически, как целые числа, использовать их.

Раствор 2

Если ваша база данных поддерживает U.I.D. или O.I.D. как varchar/string или движок базы данных или программа, которую вы используете, имеют функцию, которая генерирует UID, вы можете использовать эту функцию, отличать значение результата от строки до целого числа (разделительные разделители типа «-») и сохраняться в целое поле первичного ключа.

Резюме

Многие разработчики предпочитают, чтобы ядро ​​базы данных генерировать первичный ключ автоматически, при вставке новой записи. В случаях нравится это, тем лучше, чтобы генерировать первичный ключ в коде и назначать его напрямую. Поскольку вы используете «Entity Framework», я игнорирую, как эта библиотека обрабатывает первичные ключи.

Cheers.