Un moyen efficace de générer des nombres séquentiels sur les fédérations SQL Azure

Question

Considérant que les fédérations SQL Azure ne prennent pas en charge la propriété d'identité ou les séquences, quel serait un moyen efficace de générer des numéros séquentiels lors de l'insertion des enregistrements?

Par exemple, étant donné une table avec ces colonnes:

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])

Pour chaque commande insérée pour un locataire donné, la commande doit être incrémentée. Par exemple, pour Titulaire d'une commande serait de 1, 2, 3 ... et pour le locataire B commanderait également 1, 2, 3 ... dans une séquence indépendante. Idéalement, il ne devrait y avoir aucune lacune.

Ténaintide et commande sont des composants de la clé primaire. Leurs valeurs sont définies par l'application et ils ne sont pas liés à la question des séquences génératrices; Seul commande a le numéro séquentiel avec le sens des affaires. En outre, le télantid est la clé de distribution de la fédération.

Cet article de Blog MSDN décrit en option 1 une approche d'avoir une table contenant les séquences et à l'aide d'une procédure stockée dans une transaction distincte pour incrémenter les séquences. Chaque locataire aurait un enregistrement sur cette table tenant la dernière valeur utilisée de la séquence.

Ce serait-il l'approche optimale envisagée de l'évolutivité, de la conflit, du verrouillage des ressources? Toute autre astuce utile, compte tenu des limitations des fédérations SQL Azure?

Answer 1

Voici 2 idées supplémentaires.

Une approche serait d'avoir une mise à jour de processus distincte de ce champ pour rendre cette asynchrone, si cela est possible pour votre scénario de votre entreprise. Vous auriez besoin que le champ de commande de commande accepte les valeurs nulles pour cette approche. Pour savoir quel ordre est arrivé en premier, afin qu'il obtienne le bon ordre de commande, j'ajouterais également un champ inséréDDate. Le traitement ASYNC devient plus complexe si vous avez plusieurs rôles de travailleurs effectuant cette obligation de licenciement, auquel cas vous devrez avoir chaque processus d'attribuer les enregistrements qu'il travaille (afin que vous ayez également besoin d'un champ de propriété), ajoutez un test de concurrence pendant La mise à jour pour s'assurer que chaque processus est exécutant sur ses propres enregistrements et que l'attribution des enregistrements expire (vous avez donc également besoin d'un champ d'affectation) si le processus se bloque de manière à ce qu'il ne quitte pas d'orphelin. Pas vraiment trivial ...

Et puis vous avez l'approche de l'homme pauvre ... que lorsque les étoiles s'alignent simplement assez bien, c'est tout ce dont vous avez besoin. Si vous êtes prêt à adopter une approche de concurrence optimiste, essayez d'utiliser le numéro suivant lors de l'insertion (sélectionnez d'abord le numéro de commande maximum pour un télement et une commande donnée), puis effectuez l'insert. Si l'insert échoue (parce que vous avez ajouté un index unique sur télantides, commande de commande à cette fin), il suffit d'ajouter 1 à la commande de commande. Le vrai problème ici est la fréquence des tentatives et la probabilité de cette approche échouant. Si vous avez un processus d'entreprise relativement rationalisé, cela peut ne jamais échouer; Si toutefois, vous avez des commandes ajoutées constamment à partir de plusieurs avenues, cela peut être une approche inacceptable.

Answer 2

Je ne sais pas combien d'effort serait nécessaire pour adapter votre scénario, mais je vois aussi et voyez-y si vous pouvez le modifier: Snowmaker - Un générateur d'identification unique pour Azure(ou tout autre environnement d'hébergement de nuage)