Une clé primaire doit-elle être immuable?

Une question récente sur stackoverflow a provoqué une discussion sur l'immuabilité des clés primaires. J'avais pensé que c'était une sorte de règle selon laquelle les clés primaires devraient être immuables. S'il y a une chance qu'un jour une clé primaire soit mise à jour, j'ai pensé que vous devriez utiliser une clé de substitution. Cependant, il n'est pas dans la norme SQL et certaines fonctionnalités de "mise à jour en cascade" du SGBDR permettent de modifier une clé primaire.

Ma question est donc: est-ce toujours une mauvaise pratique d'avoir une clé primaire qui peut changer? Quels sont les inconvénients, le cas échéant, d'avoir une clé primaire mutable?

Vous n'avez besoin que de la clé primaire immuable si elle est liée à une clé étrangère, ou si elle est utilisée comme identifiant en dehors de la base de données (par exemple dans une URL pointant vers une page pour l'élément).

D'un autre côté, vous n'avez besoin d'une clé modifiable que si elle contient des informations susceptibles de changer. J'utilise toujours une clé de substitution si l'enregistrement n'a pas d'identifiant simple et immuable qui peut être utilisé comme clé.

Une clé primaire doit comprendre tous les tuples nécessaires pour déterminer l'unicité. Que les données puissent changer ou non n'a pas d'importance. Seule l'unicité du dossier importe. Telle est la conception conceptuelle de la base de données.

Lorsque nous entrons dans le domaine de l'implémentation, la chose la plus sûre à faire est simplement d'utiliser une clé de substitution.

Oui, à mon avis, une clé primaire doit être immuable.

Même s'il existe des clés candidates évidentes, j'utilise toujours une clé de substitution. Dans les rares occasions où je n'ai pas fait cela, je l'ai presque toujours regretté. Et peu importe à quel point vous pensez que la clé est immuable, vous ne pouvez pas vous protéger contre les erreurs de saisie de données - dire aux utilisateurs qu'ils ne peuvent pas modifier ce morceau d'informations car c'est une clé primaire ne se lave pas tristement.

Les mécanismes de mise en cache entre la base de données et l'utilisateur perdront leur efficacité si les clés primaires changent.

Pourquoi pas? Parce que vous voulez supprimer une colonne?

Le fait que les exigences exigent que trois colonnes soient uniques ne signifie pas qu'il doit s'agir de la clé primaire. Vous pensez peut-être que cette règle durera pour toujours (rappelez-vous lors de cette réunion lorsque le chef de département de la tête d'épingle a juré que cela ne changerait jamais? Vous savez, celui qui vient d'être licencié.), Mais ce ne sera pas le cas.

Je ne suis pas payé pour chaque mise à jour en cascade que j'implémente et un bonus si je le code moi-même.

L'ordinateur n'a besoin d'aucune signification pour une clé; À mon humble avis, les clés sont pour les ordinateurs, laissez les gens foutre le reste des données.

Ce n'est pas une mauvaise pratique d'avoir une clé dont les valeurs peuvent changer.

Les propriétés d'une bonne clé incluent la stabilité. L'immuabilité est idéale mais pas une condition préalable. L'introduction d'une clé artificielle dans un souci d'immuabilité est une mauvaise pratique.

Prenons l'exemple du numéro international normalisé du livre (ISBN) . Il est très stable mais pas immuable: parfois les éditeurs de livres font des erreurs et - horreur! - des numéros ISBN en double peuvent se produire. Cela signifie-t-il que l'ISBN ne devrait pas être accepté comme clé candidate dans une base de données informatisée? Bien sûr que non. L'un des avantages de l'ISBN est qu'il dispose d'une source fiable qui résoudra les problèmes de tous les utilisateurs dans le monde.

Il existe d'autres propriétés d'une bonne clé ISBN qui manquent à une clé entière incrémentée automatiquement sans signification, par exemple la familiarité (tout le monde dans le commerce du livre connaît ou connaît ISBN), vérifiable (l'ISBN est imprimé sur tous les livres modernes), peut être validé par référence au SGBD (l'ISBN est de largeur fixe et comprend une somme de contrôle), etc.

Tout ce qui peut être immuable devrait l'être. Il aide à garantir l'exactitude et aide lorsque vous souhaitez rendre votre application multithread.

Oui, une clé primaire doit être immuable, en plus d'être non nulle et unique. Cependant, je n'ai pas encore trouvé de base de données qui a imposé l'immuabilité des clés primaires afin que vous puissiez probablement aller de l'avant et changer leurs valeurs si vous le souhaitez vraiment.

Comme certains commentaires l'ont déjà dit, une solution consiste à utiliser une nouvelle clé primaire

Par exemple (en suivant l'exemple de @onedaywhen), supposons qu'il existe la table Books qui stocke une liste de livres et que nous avons "utilisé" pour déterminer l'ISBN comme clé primaire. Cependant, certains auteurs ont commis l'erreur de taper un mauvais ISBN, ils ont donc demandé de changer l'ISBN, cela impliquait les tâches suivantes:

• créer un nouveau registre dans la table Livres
• pointer toutes les références de l'ancien ISBN vers le nouvel ISBN. (*)
• Et enfin, supprimez l'ancien registre de la table Books.

(*) cela pourrait être trivial pour trouver toutes les références d'un modèle de base de données qui utilise des clés étrangères mais certains modèles n'en ont pas.

Table Books
ISBN  is the primary key
NAME is a simple field.
etc.

Nous le changeons comme

Table Books
InternalBookId as the primary key
ISBN as a simple field or an indexed field.
NAME is a simple field.
etc.

Où le nouvel InternalBookId pourrait même être une valeur autonumérique.

Les inconvénients à ce sujet:

• il ajoute un nouveau champ qui utilise plus d'espace / de ressources.

• cela pourrait nécessiter de réécrire le modèle entier.

• le nouveau modèle pourrait être moins explicite.

Le pro

• Permet de muter la "clé primaire".
• Permet même de supprimer ou de refactoriser la "clé primaire", par exemple, pour changer Livres en ISBN-13 est si simple que de supprimer l'ancienne colonne et d'en créer une nouvelle

Nouvelle table:

Table Books
InternalBookId as the primary key
ISBN13 is a new field.
NAME is a simple field.
etc.