Динамический последовательный тождественный столбец и условные ограничения?

Question

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

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

ProductTypeId   SerialPrefix SerialStartRange     SerialEndRange
--------------- ------------ -------------------- --------------------
1               2            2000000000           2999999999
2               1            1000000000           1999999999
3               4            4000000000           4999999999
4               3            3000000000           3999999999
5               501          5010000000           5019999999
6               500          5000000000           5009999999
7               601          6010000000           6019999999
8               600          6000000000           6009999999
...             ...          ...                  ...

2) Желаемые результаты

Продукты - это таблица атрибутов продукта, которую я сокращу до важных битов..

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

ProductId   ProductTypeId   SerialNumber
----------- --------------- ------------
1           2               100000000
2           2               100000001
3           2               100000002
4           2               100000003
5           2               100000004
6           2               100000005
7           2               100000006
8           2               100000007
9           4               300000000
10          4               300000001
11          4               300000002

И так далее ...

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

Когда требуется вставить продукт, мне предоставляется ProductTypeId, а после вставки яожидается, что сгенерирует серийный номер, как определено диапазоном в таблице SerialEnum.

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

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

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

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

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

Если у кого-то есть опыт или идеи, я был бы очень благодарен, если бы вы отскочили от меня!

Answer 1

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

Делайте это в коде, в виде веб-службы или чего-либо более удобного для вашего приложения.Добавьте столбец к ProductSerialEnum, называемый чем-то вроде NextAvailableValue, который начинается со значения в SerialStartRange.Код запускается в этой таблице при запуске.

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

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

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

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

Answer 2

мы не можем записать серийные номера

и

Однако база данных получает тонну одновременного трафика

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

Если вам разрешено, вы всегда можете назначить серийные номера после массового события.Это повлечет за собой наличие столбца fast, sequence или identity для первичного ключа и ввода пустого серийного номера.Периодически вы сканируете базу данных на наличие пустых SN и выделяете их с помощью ROW_NUMBER () на основе порядка (но не значения) суррогатного идентификатора.

Это гарантирует отсутствие пробелов, но будет время, когда не все продуктыбудет иметь серийный номер.