Nous y revoilà, le vieil argument est toujours d'actualité...
Serait-il préférable d'avoir une clé de gestion comme clé primaire ou plutôt un identifiant de substitution (c'est-à-dire une identité SQL Server) avec une contrainte unique sur le champ de la clé de gestion ?
Veuillez fournir des exemples ou des preuves à l'appui de votre théorie.
Pour rappel, ce n'est pas une bonne pratique de placer des index en grappe sur des clés de substitution aléatoires, c'est-à-dire des GUID qui se lisent XY8D7-DFD8S, car le serveur SQL n'a pas la capacité de trier physiquement ces données. Vous devriez plutôt placer des index uniques sur ces données, bien qu'il puisse être également bénéfique de simplement exécuter SQL profiler pour les opérations de la table principale et ensuite placer ces données dans le Database Engine Tuning Advisor (conseiller de réglage du moteur de base de données).
Voir le fil @ http://social.msdn.microsoft.com/Forums/en-us/sqlgetstarted/thread/27bd9c77-ec31-44f1-ab7f-bd2cb13129be
Dans le cas d'une base de données ponctuelle, il est préférable d'avoir une combinaison de clés de substitution et de clés naturelles. Certains attributs d'un membre ne changent jamais, par exemple sa date de naissance, mais son nom peut changer. Créez donc une table Membre avec une clé de substitution membre_id et une colonne pour la date de naissance. Créez une autre table appelée nom de la personne et ayez des colonnes pour l'identifiant du membre, le nom_du_membre, le nom_du_membre, la date_de_mise_à_jour. Dans cette table, la clé naturelle serait member_id + date_updated.
Il n'y a pas de quoi s'emballer. Je suis d'abord un développeur, et je me préoccupe donc principalement de donner aux utilisateurs une application qui fonctionne.
J'ai travaillé sur des systèmes avec des clés naturelles et j'ai dû passer beaucoup de temps à m'assurer que les changements de valeur se répercutaient.
J'ai travaillé sur des systèmes n'utilisant que des clés de substitution, et le seul inconvénient a été le manque de données dénormalisées pour le partitionnement.
La plupart des développeurs PL/SQL traditionnels avec lesquels j'ai travaillé n'aimaient pas les clés de substitution en raison du nombre de tables par jointure, mais nos bases de données de test et de production n'ont jamais fait de vagues ; les jointures supplémentaires n'ont pas affecté les performances de l'application. Avec les dialectes de base de données qui ne supportent pas les clauses telles que "X inner join Y on X.a = Y.b", ou les développeurs qui n'utilisent pas cette syntaxe, les jointures supplémentaires pour les clés de substitution rendent les requêtes plus difficiles à lire, et plus longues à taper et à vérifier : voir l'article de @Tony Andrews. Mais si vous utilisez un ORM ou tout autre framework de génération SQL, vous ne le remarquerez pas. La saisie tactile permet également d'atténuer ce problème.
Ce n'est peut-être pas tout à fait en rapport avec le sujet, mais j'ai un mal de tête avec les clés de substitution. Oracle pre-delivered analytics crée des SKs auto-générées sur toutes ses tables de dimension dans l'entrepôt, et il les stocke également sur les faits. Ainsi, à chaque fois qu'elles (les dimensions) doivent être rechargées suite à l'ajout de nouvelles colonnes ou qu'elles doivent être renseignées pour tous les éléments de la dimension, les SK attribuées lors de la mise à jour les désynchronisent des valeurs originales stockées dans le fait, ce qui oblige à un rechargement complet de toutes les tables de fait qui s'y rattachent. Je préférerais que, même si le SK était un nombre sans signification, il y ait un moyen de l'empêcher de changer pour les enregistrements originaux/anciens. Comme beaucoup le savent, les solutions prêtes à l'emploi répondent rarement aux besoins d'une organisation, et nous devons constamment les personnaliser. Notre entrepôt contient maintenant des données qui valent trois ans, et les recharges complètes à partir des systèmes financiers d'Oracle sont très volumineuses. Dans mon cas, elles ne sont donc pas générées par la saisie des données, mais ajoutées dans un entrepôt pour améliorer les performances des rapports. Je comprends, mais les nôtres changent et c'est un cauchemar.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
25 votes
@Joachim Sauer : Un argument sur la question de savoir si une chose est subjective peut lui-même être subjectif, sans que cela soit lié d'une quelconque manière à l'objectivité ou à la subjectivité de la chose en question. A moins que vous ne soyez prêt à énoncer les critères objectifs exacts qui font qu'une chose est objective. Il y a des choses appelées "concepts ouverts", comme le nombre de poils nécessaires pour faire une barbe. On peut objectivement dire qu'une personne qui n'a pas de poils au menton n'a pas de barbe, et qu'une personne qui a 5 000 poils d'un pouce de long a une barbe, mais quelque part au milieu, un jugement subjectif est nécessaire pour faire une détermination objective.
1 votes
@Manrico : il suffit de se poser la question suivante : si je n'utilise pas de clé de substitution, ma clé primaire sera-t-elle toujours immuable ? Si la réponse est non, alors vous devriez sérieusement envisager l'utilisation d'une clé de substitution. De même, si la clé primaire est composée, même partiellement, d'entrées utilisateur, vous devez envisager d'utiliser une clé de substitution. Pourquoi ? En raison du risque d'anomalies dans les données.
1 votes
@TylerRick Mais ce n'est pas une bonne question. Elle demande une solution applicable à toutes les situations, alors qu'il n'y en a manifestement pas, comme le prouve la "guerre de religion" dont l'auteur de la question est parfaitement conscient (citation : "Here we go again, the old argument still arises..."). Au lieu de se demander si le monde a changé et si l'on a enfin trouvé une raison convaincante de choisir un camp à tout moment, il vaut mieux poser cette question encore et encore pour chaque situation concrète, et poster sur SO quand on n'est pas sûr. Cela ne fait que susciter le dogmatisme.