Modo efficiente per generare numeri sequenziali sulle federazioni SQL Azure

Question

Considerando che le federazioni SQL Azure non supportano la proprietà o le sequenze dell'identità, quale sarebbe un modo efficiente per generare numeri sequenziali quando inseriscono i record?

Ad esempio, data una tabella con queste colonne:

CREATE TABLE [dbo].[Orders] (
    [TenantId] [uniqueidentifier] NOT NULL,
    [OrderId] [uniqueidentifier] NOT NULL,
    [OrderNumber] [int] NOT NULL
    CONSTRAINT [PK_Orders] PRIMARY KEY CLUSTERED (
        [TenantId] ASC,
        [OrderId] ASC
    )
) FEDERATED ON ([FederationKey] = [TenantId])

.

Per ogni ordine inserito per un determinato inquilino, è necessario incrementato l'ordine. Ad esempio, per Tentant A OrderID sarebbe 1, 2, 3 ... e per il Tenant B OrderID sarebbe anche 1, 2, 3 ... in una sequenza indipendente. Idealmente non ci dovrebbero essere lacune.

Tenantalido e OrderID sono componenti della chiave primaria. I loro valori sono impostati dall'applicazione e non sono collegati al problema della generazione di sequenze; Solo OrderID ha il numero sequenziale con il significato aziendale. Inoltre, Tenantid è la chiave di distribuzione della Federazione.

Questo articolo del blog msdn descrive nell'opzione 1 Un approccio di avere una tabella che tiene le sequenze e utilizzando una procedura memorizzata in una transazione segregata per incrementare le sequenze. Ogni inquilino avrebbe un record su questa tabella che tiene l'ultimo valore utilizzato della sequenza.

Sarebbe l'approccio ottimale considerando scalabilità, contesa, blocco delle risorse? Qualche altro trucco utile, considerando i limiti delle federazioni SQL Azure?

Answer 1

Ecco 2 idee aggiuntive.

Un approccio sarebbe quello di avere un processo separato aggiornare quel campo per rendere questo asincrono, se questo è qualcosa per il tuo scenario d'affari. Dovresti avere il campo ORDORNumber accettare valori nullo per questo approccio. Per sapere quale ordine è arrivato per primo, in modo che ottiene il numero di ordine corretto, aggiungerei anche un campo inserito. L'elaborazione ASYNC diventa più complessa Se si dispone di più ruoli di lavoratori che eseguono questo dazio per la ridondanza, nel qual caso dovrai avere ogni processo assegnare se stesso i record che sta funzionando (quindi è necessario anche un campo di proprietà), aggiungere un test di concorrenza durante L'aggiornamento per garantire che ogni processo si sta eseguendo sui propri record e si presentano l'assegnazione dei record (quindi è necessario anche un campo di assegnazione) se il processo si blocca in modo che non lascia orfani. Non proprio banale ...

E poi hai l'approccio dell'uomo povero ... che quando le stelle si allineano semplicemente abbastanza bene potrebbero essere tutto ciò di cui hai bisogno. Se sei disposto ad avere un approccio di concorrenza ottimista, provare a utilizzare il numero successivo durante l'inserimento (selezionare il numero massimo di ordine per un determinato Tenantid e OrderID), quindi eseguire l'inserto. Se l'inserto fallisce (perché hai aggiunto un indice unico su TenantID, ordinare il numero di ordini per questo scopo), aggiungi solo 1 al numero di ordine. Il vero problema qui è la frequenza dei tentativi e la probabile probabilità di questo approccio che fallisce. Se si dispone di un processo aziendale relativamente aerodinamico, questo potrebbe effettivamente fallire; Se tuttavia hai aggiunto gli ordini costantemente da più viali, questo potrebbe essere un approccio inaccettabile.

Answer 2

Non è sicuro che lo sforzo sarebbe necessario per adattarsi al tuo scenario, ma anche a guardare questo e vedere se riesci a modificarlo: Snowmaker - Un generatore di ID univoco per Azure(o qualsiasi altro ambiente di hosting cloud)