Бих използвал поле IDENTITY като първичен ключ, за да осигуря уникално увеличаващия се ID за всеки елемент в опашката и да залепя клъстерен индекс върху него. Това ще представлява реда, в който елементите са поставени на опашка.
За да запазите елементите в таблицата на опашката, докато ги обработвате, ще ви е необходимо поле „състояние“, за да посочите текущото състояние на конкретен елемент (напр. 0=чака, 1=обработва се, 2=обработва се). Това е необходимо, за да се предотврати обработката на даден елемент два пъти.
Когато обработвате елементи в опашката, ще трябва да намерите следващия елемент в таблицата, който НЕ се обработва в момента. Това трябва да бъде по такъв начин, че да се предотврати едновременното вземане на един и същ елемент за обработка от множество процеси, както е показано по-долу. Обърнете внимание на подсказки за таблицата UPDLOCK и READPAST, които трябва да знаете, когато внедрявате опашки.
напр. в рамките на sproc, нещо като това:
DECLARE @NextID INTEGER
BEGIN TRANSACTION
-- Find the next queued item that is waiting to be processed
SELECT TOP 1 @NextID = ID
FROM MyQueueTable WITH (UPDLOCK, READPAST)
WHERE StateField = 0
ORDER BY ID ASC
-- if we've found one, mark it as being processed
IF @NextId IS NOT NULL
UPDATE MyQueueTable SET Status = 1 WHERE ID = @NextId
COMMIT TRANSACTION
-- If we've got an item from the queue, return to whatever is going to process it
IF @NextId IS NOT NULL
SELECT * FROM MyQueueTable WHERE ID = @NextID
Ако обработката на елемент е неуспешна, искате ли да можете да опитате отново по-късно? Ако е така, ще трябва или да нулирате състоянието обратно на 0 или нещо подобно. Това ще изисква повече обмисляне.
Като алтернатива, не използвайте таблица на база данни като опашка, а нещо като MSMQ - просто реших да добавя това в сместа!
