В «хорошие времена» я использовал базу данных Sybase SQL Anywhere.У него была функция, позволяющая избежать коллизий, когда несколько пользователей создавали новые записи: существовала отдельная таблица значений ключей, которая использовалась бы для распределения блоков уникальных ключей в клиентские приложения, которые будут использоваться при последующих вставках в другие таблицы.Когда пул ключей клиента становится низким, клиент запрашивает другой блок ключей с сервера.Ключи могут быть специфическими для отдельной таблицы (то есть каждая таблица имеет свой собственный пул ключей), или ключи могут быть «общими» для таблиц, так что INSERT INTO Table1 может использовать Key=100, а следующий INSERT INTO Table2 будетзатем используйте Key=101.
Преимущество этого пула ключей заключается в том, что первичный ключ, назначенный на стороне клиента, может также использоваться в качестве внешнего ключа при создании вставок в другие таблицы - все на стороне клиента без предварительной фиксации.транзакция, если пользователь в конечном итоге откажется от новых данных.
Я искал похожую функциональность, но мне кажется, что я только нахожу репликацию и зеркалирование базы данных, а не что-то в таблице ключей.
Мы используем общую базу данных и несколько клиентов, на которых запущено приложение VB.NET для доступа и создания данных.
Базовая таблица, которую я имел в виду, выглядит примерно так:
CREATE TABLE [KeyPool] (
[KeyNo] [int] IDENTITY PRIMARY KEY NOT NULL,
[AssignedTo] [varchar](50) NULL,
[Status] [nchar](10) NULL,
[LastTouched] [datetime2] NULL,
)
Столбцы Status и LastTouched позволили бы восстановить «потерянные ключи», если бы требовалась сборка мусора, но это на самом деле не нужно.На самом деле, наличие единственной строки, в которой хранится последнее значение ключа, данное клиенту, было бы минимальным требованием: просто раздайте ключи в блоках по 1000 по запросу и увеличьте счетчик, чтобы узнать, какой блок раздать следующим.Однако без таблицы, которая отслеживает, у кого какие ключи, будет много «потерянных» значений ключей (что может быть или не быть проблемой в зависимости от потенциального числа записей, ожидаемых в базе данных).
Я ищу какие-либо "стандартные" методы в SQL Server, прежде чем выйти и дублировать усилия по созданию собственного решения.