Re-graine de la colonne d'identité: quand est-ce nécessaire?

Au cours de l'une des dernières leçons à l'université (je suis étudiant), le professeur nous a demandé de développer une base de données (MySQL Server si c'est important) et une petite application cliente qui consommerait la base de données comme source de données.

L'une des exigences était que la colonne d'identité (qui est le PK dans chaque table) doit être séquentielle, car c'est une bonne pratique (selon les mots du conférencier). Autrement dit, lorsque la ligne du tableau est supprimée, son PK doit être réutilisé dans les insertions suivantes. J'ai une connaissance moyenne des SGBDR, des PK et des colonnes d'identité. D'après ce que je comprends, cette colonne d'identité est juste un moyen de laisser DB générer automatiquement des PK lors de l'insertion de lignes et rien de plus. Et la valeur de la colonne d'identité ne doit en aucun cas être liée aux attributs de ligne (tant qu'elle n'est pas une clé naturelle).

Cette exigence (colonne d'identité strictement séquentielle) était suspecte pour moi. J'ai essayé de demander au conférencier ce qui ne va pas si l'identité n'est pas séquentielle (avec des lacunes causées par des suppressions), mais j'ai obtenu une réponse très abstraite comme "c'est pratique pour les utilisateurs et utile pour les administrateurs de base de données qui maintiennent la base de données". Pas d'exemples précis. L'argument «pratique pour les utilisateurs» semble idiot, car il n'a aucune signification dans le domaine des affaires.

Je suis donc curieux de savoir si ces raisons sont réelles? Je ne peux penser qu'à un cas où le réamorçage de la colonne d'identité est requis - lorsque l'espace d'identité est épuisé. Mais il s'agit davantage d'un problème de conception lorsque le type de colonne d'identité a été mal choisi, par exemple simple intau lieu de bigintou uniqueidentifierlorsque la table contient des milliards de lignes. Supposons qu'une colonne d'identité soit un index clusterisé: les lacunes dans la colonne d'identité peuvent-elles affecter les performances de l'index? Peut-être existe-t-il d'autres raisons réelles de réamorcer automatiquement la colonne d'identité après chaque suppression, je ne suis pas au courant?

Merci d'avance!

Autrement dit, lorsque la ligne du tableau est supprimée, son PK doit être réutilisé dans les insertions suivantes.

De quel univers est votre conférencier ??

C'est extrêmement inefficace. Si vous essayez de le faire, vous réduirez vos perspectives de performance d'un facteur 10.

Si vous avez besoin de nombres sans espace pour des raisons d'audit, créez-les explicitement, pas directement à partir des outils de base de données. Et ne supprimez jamais les lignes, mais marquez-les comme "supprimées". Cela ajoutera au désordre des requêtes, car ils devront ignorer ces lignes.

Dans MySQL, InnoDB nécessite l'existence d'un unique PRIMARY KEYpour chaque table. Mais c'est l'étendue de l'exigence. La clé peut même être une chaîne.

Les lacunes sont une commodité pour les utilisateurs et les administrateurs de base de données, pas un inconvénient.

Je peux penser à un cas où le gapless serait pratique - le découpage en groupes de 100 lignes à la fois. Mais il existe une solution de contournement simple à l'aide LIMIT 100,1.

Les lacunes n'ont aucun impact sur les performances. Cela inclut les index non numériques. Et des index non uniques. Et des index composites.

Bien sûr, vous pouvez manquer d'ID. Je pense que je l'ai vu se produire deux fois en près de deux décennies d'utilisation de MySQL. Je peux aussi m'inquiéter d'être frappé par un astéroïde. C'est bas sur ma liste de choses qui me tiennent éveillé la nuit.

Les lacunes se produisent à partir (au moins): INSERT IGNORE, IODKU, REPLACE, DELETE, ROLLBACK(explicite, ou en raison de tomber en panne), la réplication multi-maître (y compris Galera et groupe de réplication). Voulez-vous vraiment trouver des solutions de contournement pour ceux-là?!

N'hésitez pas à nous faire vérifier tout ce que le conférencier dit suspect.

La réutilisation d'une valeur d'identité doit en général être découragée. Soit la valeur est utilisée entièrement en interne, auquel cas sa valeur réelle est sans importance, soit elle est également utilisée en externe, auquel cas la réutilisation de la valeur entraînera très probablement une erreur d'identification.

Prenez le cas évident d'une facture ou d'un numéro de bon de commande, ceux-ci peuvent facilement provenir d'une colonne d'identité et être exposés à l'extérieur, mais vous ne voudrez jamais les réutiliser précisément pour cette raison. Les deux se réfèrent à des transactions spécifiques que vous ne voudriez pas confondre.

La résolution de ces problèmes peut être très compliquée lorsque des sociétés fusionnent ou sont acquises. Créer de tels problèmes exprès? Pas sage.

La réutilisation des valeurs PK id pose des problèmes et doit généralement être évitée.

Tout d'abord, l'implémentation des colonnes auto_increment ne fournit pas la garantie d'être sans faille. En effet, des lacunes se produiront si vous annulez un insert sur une colonne d'incrémentation automatique.

Deuxièmement, l'ID d'espace peut faire référence à des données existantes qui n'ont pas été supprimées (en raison de contraintes FK manquantes). S'ils se traduisent par des numéros de membre communiqués en dehors du système, cela pose des risques potentiels pour l'identité commerciale.

Troisièmement, bigint unsignedne manquera pas d'ID pendant un temps significatif, même avec un taux d'insertion extrêmement élevé.

La plus grande difficulté avec les lacunes vient des auditeurs qui insistent sur le fait qu'il s'agit d'une faille d'audit. Pour les administrateurs de base de données, ils savent qu'il existe des lacunes et pourquoi.

Je ne ferai pas écho aux commentaires de tous les autres selon lesquels la réutilisation d'un PK est une mauvaise idée, mais je suis tombé sur des moments où une colonne d'identité devait être réensemencée.

Corruption de l'index PK lui-même.

Certes, cela utilisait MS-SQL et il y a de nombreuses années, mais c'est toujours pertinent. Il y a de nombreuses années pour l'entreprise pour laquelle je travaille, quelqu'un a pensé que ce serait une bonne idée de réutiliser les PC comme serveurs dans nos 150+ sites distants après qu'ils étaient trop vieux pour être utilisés par les clients, puis de les coller dans un placard sans ventilation. Quand non Parce que nous savons tous qu'un tas d'ordinateurs indésirables de 10 ans dans une petite pièce avec des températures de plus de 120 bases de données critiques en cours d'exécution ne peut que produire de bonnes choses. Comme 40% de taux d'échec et moi, je repense mon choix de carrière. Nous répliquions les données au siège du corp, mais le plus souvent, ces échecs entraînaient de mauvaises choses dans les bases de données. L'une de ces choses était que la base de données avait des index corrompus qui pourraient bloquer la base de données et le processus de réplication. Deux fois dans cet excellent environnement, la seule solution pour corriger la réplication était de réamorcer les index, puis de rétablir la réplication. Nous avons remplacé les serveurs plus tard avant de les abandonner complètement.