Discussion :

[faressam]

Bonjour,
depuis un certains temps j'ai posé ma question
concernant la recherche d'une clés, de tel sorte qu'elle soit la meilleur clé
pour ne pas altérer les données, (effacer ou augmenter les données).

cela dit, j'ai eu une proposition de mon responsable,
qui était de ne pas se prendre la tête :

Si on a : data1/ data2/ ..... data 30 : Pas la peine de chercher une clé, mais faire : Data1 + data2...+data 30 = Clé Primaire (clé unique),

mais je m'oppose à cela pour 2 raisons ou Hypothèses :

1) Lenteur de la Sélection ou peut être de l'insertion des données.
2) Que si la clé dépasse 3 attributs ce n'est plus une clé.

Merci de me donner votre avis, en général sur la question,
et surtout vôtre avis sur mes hypothèses.

[CinePhil]

Une bonne clé primaire est de type entier non nul non signé et auto-incrémentée.

Inutile de chercher autre chose.

Mais je comprends peut-être mal le contenu de votre message ?

la recherche d'une clés, de tel sorte qu'elle soit la meilleur clé
pour ne pas altérer les données, (effacer ou augmenter les données).

Une clé n'altère pas les données, elle en assure seulement l'identification unique.

Si on a : data1/ data2/ ..... data 30 : Pas la peine de chercher une clé, mais faire : Data1 + data2...+data 30 = Clé Primaire (clé unique),

mais je m'oppose à cela

Et vous avez bien raison de vous y opposer !
Une clé de 30 colonnes, ça devient ingérable, à la fois pour le programmeur et pour le SGBD.

1) Lenteur de la Sélection ou peut être de l'insertion des données.

Effectivement, ça risque de vite devenir très lent !

2) Que si la clé dépasse 3 attributs ce n'est plus une clé.

Ca par contre, c'est faux.
Si vous avez dans le MCD une relation qui met en jeu 5 entités, vous aurez, pour la table issue de cette relation, une clé primaire composée des 5 identifiants des entités.

[pacmann]

Une bonne clé primaire est de type entier non nul non signé et auto-incrémentée.

Bof. Surtout vu ta dernière remarque sur les clefs composites.

Inutile de chercher autre chose.

Re-bof. Je suppose que faressam est ici pour trouver des arguments... et ne pas juste annoncer à son chef : "C'est pas bon, inutile de discuter"

Effectivement, ça risque de vite devenir très lent !

Hmmm, faut pas exagérer non plus. Faudrait faire le test... mais pour des accès ponctuels et très sélectifs, il n'y a pas de raisons que ça rame tant que ça (même si ça va probablement augmenter le niveau du b-tree).
Même en modification, pour l'instant il ne s'agit toujours que d'un index à mettre à jour (certes il y a à chaque fois la contrainte d'unicité à vérifier)

[Arkhena]

Bof. Surtout vu ta dernière remarque sur les clefs composites.

Bonjour,

Je pense que ce que Cinephil voulait dire, c'est qu'à moins d'avoir une table qui est la résultante d'une relation n-n, la meilleure clef primaire est de type entier non nul non signé et auto-incrémentée.

S'il s'agit d'une table issue d'une relation n-n, la meilleure clef primaire et l'ensemble des clefs étrangères.

Arkhena

[CinePhil]

Je pense que ce que Cinephil voulait dire, c'est qu'à moins d'avoir une table qui est la résultante d'une relation n-n, la meilleure clef primaire est de type entier non nul non signé et auto-incrémentée.

S'il s'agit d'une table issue d'une relation n-n, la meilleure clef primaire et l'ensemble des clefs étrangères.

C'est exactement ça !

SQLPro avait je crois écrit de très bons arguments sur le fait qu'une bonne clé est de type entier non null et auto-incrémentée mais je ne retrouve pas l'article où cela figure.

[pacmann]

Oui Cinephil, je sais que c'est à cela que tu faisais référence

http://sqlpro.developpez.com/cours/clefs/

En soit, je ne nie pas qu'une clé entière auto incrémentée soit une bonne idée.
Mais là, c'était dans l'autre sens :

Une bonne clé primaire est de type entier non nul non signé et auto-incrémentée.

Mais je suis toujours un tout petit peu interpelé par les règles intransigeantes et bues comme parole d'évangile. Je pense que nous devrions profiter du fait que nous ayons un cerveau pour évaluer ces axiomes / dogmes, peser du pour et du contre, rechercher des avis différents, ...
En gros, même si les articles de SQL Pro sont souvent très bons et apportent beaucoup à la littérature SQL francophone du net, cela ne doit pas nous empêcher de penser de temps en temps par nous même !

Et il y a plein d'autres exemples (pas par rapport à SQL Pro, mais de manière générale sur notre propension au moutonisme) : string aggregation, sélectivité et ordre des colonnes dans un index, les règles de performances (NOT) EXISTS / (NOT) IN / LEFT OUTER JOIN, ...

[pacmann]

Salut !

Les responsables... devraient se contenter de faire de la responsabilité

1) Lenteur de la Sélection ou peut être de l'insertion des données.
2) Que si la clé dépasse 3 attributs ce n'est plus une clé.

Je ne sais pas si tes arguments sont vraiment bons...
(en tous cas le second est à mon sens faux)

Ton index de 30 colonnes va être énorme, et donc pour parcourir des sélections, ça va être plus long.

Par ailleurs, à chaque fois qu'une donnée sera modifiée, ça mettra à jour l'index (perte de temps, donc).

Si tes lignes doivent être référencées par une autre table, la référence sera plus petite, plus pratique, plus maniable si elle consiste en un identifiant (plutôt que l'ensemble des colonnes). Et bien sûr, toujours dans le cas des références externes, la modification d'une des données serait assez lourde (avec des violation de contraintes ou des cascades...)

Petit argument supplémentaire : normalement, il y a un modèle de données. D'une manière ou d'une autre, on définit des élements, entités, qui correspondent à une certaine logique...
Avec votre méthode, c'est comme si au lieu de t'appeler "faressam", je préférais dire : "Date d'inscription: janvier 2005", "Localisation: Maroc, Canada, France", "Âge: 25", "Messages: 898", ...
=> Ce n'est pas vraiment ce qui t'identifie...

Enfin bref, si vous pouvez éviter cette méthode, faites-le !

[CinePhil]

Avec votre méthode, c'est comme si au lieu de t'appeler "faressam", je préférais dire : "Date d'inscription: janvier 2005", "Localisation: Maroc, Canada, France", "Âge: 25", "Messages: 898", ...
=> Ce n'est pas vraiment ce qui t'identifie...

D'autant plus que l'âge et le nombre de messages changent (au moins ces informations là) et en principe, on ne met jamais à jour une clé primaire.

[faressam]

D'autant plus que l'âge et le nombre de messages changent (au moins ces informations là) et en principe, on ne met jamais à jour une clé primaire.

Si je comprends bien, les éléments (3 ou 30) qui fabriquent
une clé primaire, ne doivent pas être modifiés ?

Pour la question d'altérer, je voulais dire, que si on met en place une clés pas optimale ou bonne, des données ne seront peut être pas prit en considèration
ou même le contraire, des données en plus dont on en a pas besoin.

exemple:
Si on indexe le Forumiste par son pays, bein on aura le même utilisateur
2 ou 3 fois : Faressam qui se balade entre Canada, Maroc et France.

Faressam : Maroc
Faressam : Canada
Faressam : France