Séquence vs identité

SQL Server 2012 introduit en Sequencetant que nouvelle fonctionnalité, identique à Oracle et Postgres. Où les séquences sont-elles préférées aux identités? Et pourquoi avons-nous besoin de séquences?

Je pense que vous trouverez votre réponse ici

En utilisant l'attribut d'identité pour une colonne, vous pouvez facilement générer des nombres à incrémentation automatique (qui sont souvent utilisés comme clé primaire). Avec Sequence, ce sera un objet différent que vous pourrez attacher à une colonne de table lors de l'insertion. Contrairement à l'identité, le numéro suivant de la valeur de la colonne sera extrait de la mémoire plutôt que du disque - cela rend la séquence beaucoup plus rapide que l'identité. Nous verrons cela dans les exemples à venir.

Et ici :

Séquences: les séquences sont demandées par la communauté SQL Server depuis des années et sont incluses dans cette version. La séquence est un objet défini par l'utilisateur qui génère une séquence d'un nombre. Voici un exemple utilisant Sequence.

et ici aussi:

Un objet de séquence SQL Server génère une séquence de nombres tout comme une colonne d'identité dans les tables SQL. Mais l'avantage des numéros de séquence est que l'objet de numéro de séquence n'est pas limité par une seule table SQL.

et sur msdn, vous pouvez également en savoir plus sur l'utilisation et pourquoi nous en avons besoin ( ici ):

Une séquence est un objet lié au schéma défini par l'utilisateur qui génère une séquence de valeurs numériques selon la spécification avec laquelle la séquence a été créée. La séquence de valeurs numériques est générée dans un ordre croissant ou décroissant à un intervalle défini et peut effectuer un cycle (répéter) comme demandé. Les séquences, contrairement aux colonnes d'identité, ne sont pas associées aux tables. Une application fait référence à un objet séquence pour recevoir sa valeur suivante. La relation entre les séquences et les tables est contrôlée par l'application. Les applications utilisateur peuvent référencer un objet séquence et coordonner les clés de valeurs sur plusieurs lignes et tables.

Une séquence est créée indépendamment des tables à l'aide de l'instruction CREATE SEQUENCE. Les options vous permettent de contrôler l'incrément, les valeurs maximale et minimale, le point de départ, la capacité de redémarrage automatique et la mise en cache pour améliorer les performances. Pour plus d'informations sur les options, consultez CREATE SEQUENCE.

Contrairement aux valeurs de colonne d'identité, qui sont générées lorsque des lignes sont insérées, une application peut obtenir le numéro de séquence suivant avant d'insérer la ligne en appelant la fonction NEXT VALUE FOR. Le numéro de séquence est attribué lorsque NEXT VALUE FOR est appelé même si le numéro n'est jamais inséré dans une table. La fonction NEXT VALUE FOR peut être utilisée comme valeur par défaut pour une colonne dans une définition de table. Utilisez sp_sequence_get_range pour obtenir une plage de plusieurs numéros de séquence à la fois.

Une séquence peut être définie comme n'importe quel type de données entier. Si le type de données n'est pas spécifié, une séquence utilise par défaut bigint.

La séquence et l'identité sont toutes deux utilisées pour générer un numéro automatique, mais la principale différence est que l'identité dépend de la table et la séquence est indépendante de la table.

Si vous avez un scénario dans lequel vous devez maintenir un numéro automatique globalement (dans plusieurs tables), vous devez également redémarrer votre intervalle après un nombre particulier et vous devez le mettre en cache également pour les performances, voici l'endroit où nous avons besoin de séquence et non identité.

Bien que les séquences offrent plus de flexibilité que les colonnes d'identité, je n'ai pas trouvé qu'elles avaient des avantages en termes de performances.

J'ai trouvé que les performances utilisant l'identité étaient systématiquement 3 fois plus rapides que l'utilisation de la séquence pour les insertions par lots.

J'ai inséré environ 1,5 million de lignes et les performances étaient:

• 14 secondes pour l'identité
• 45 secondes pour la séquence

J'ai inséré les lignes dans une table qui utilisait un objet séquence via une table par défaut:

NEXT VALUE for <seq> for <col_name>

et a également essayé de spécifier la valeur de séquence dans l'instruction select:

SELECT NEXT VALUE for <seq>, <other columns> from <table>

Les deux étaient le même facteur plus lent que la méthode d'identité. J'ai utilisé l'option de cache par défaut pour la séquence.

L'article référencé dans le premier lien d'Arion montre les performances pour les insertions ligne par ligne et la différence entre l'identité et la séquence était de 16,6 secondes à 14,3 secondes pour 10 000 insertions.

L'option Caching a un impact important sur les performances, mais l'identité est plus rapide pour les volumes plus élevés (+ 1M de lignes)

Voir ce lien pour une analyse approfondie selon le commentaire d'utly4life.

Je sais que c'est un peu vieux, mais je voulais ajouter une observation qui m'a mordu.

Je suis passé de l'identité à la séquence pour avoir mes index dans l'ordre. J'ai découvert plus tard que la séquence ne transférait pas avec la réplication. J'ai commencé à avoir des violations de clé après avoir configuré la réplication entre deux bases de données car les séquences n'étaient pas synchronisées. juste quelque chose à surveiller avant de prendre une décision.

Je trouve que la meilleure utilisation des séquences n'est pas de remplacer une colonne d'identité mais de créer un champ de type "Numéro de commande".

En d'autres termes, un numéro de commande est exposé à l'utilisateur final et peut être accompagné de règles métier. Vous voulez qu'elle soit unique, mais le simple fait d'utiliser une colonne d'identité n'est pas vraiment correct non plus.

Par exemple, différents types de commande peuvent nécessiter une séquence différente, vous pouvez donc avoir une séquence pour la commande Internet, par opposition aux commandes internes.

En d'autres termes, ne considérez pas une séquence comme un simple remplacement d'identité, pensez-y comme étant utile dans les cas où une identité ne correspond pas aux exigences de l'entreprise.

Récemment, il y avait quelque chose à considérer pour l'identité par rapport à la séquence. Il semble que MSFT suggère maintenant une séquence si vous souhaitez conserver l'identité sans lacunes. Nous avons eu un problème où il y avait d'énormes lacunes dans l'identité, mais sur la base de cette déclaration mise en évidence, cela expliquerait notre problème selon lequel SQL a mis en cache l'identité et après le redémarrage, nous avons perdu ces numéros.

https://docs.microsoft.com/en-us/sql/t-sql/statements/create-table-transact-sql-identity-property?view=sql-server-2017

Valeurs consécutives après le redémarrage du serveur ou d'autres échecs - SQL Server peut mettre en cache les valeurs d'identité pour des raisons de performances et certaines des valeurs attribuées peuvent être perdues lors d'une défaillance de la base de données ou du redémarrage du serveur. Cela peut entraîner des lacunes dans la valeur d'identité lors de l'insertion. Si les lacunes ne sont pas acceptables, l'application doit utiliser son propre mécanisme pour générer des valeurs clés. L'utilisation d'un générateur de séquence avec l'option NOCACHE peut limiter les écarts aux transactions qui ne sont jamais validées.