Probleme d'index

**yagogak** · 01/02/2006, 15h46

Bonjour à tous,

J'ai une question concernant les clé primaires.

je dois stocké pour définir un utilisateur d'une application un nombre très important d'information, certaines de ces information seront solicitées très frequement alors que d'autres seront selectionnée que plus rarement.

il m'apparait donc evident d'éclater les données concernant les utilisateurs sur plusieurs table.( en tout 6 tables pour différents type de données, plus les jointures pour des données telles que les villes)

Va donc se poser le probleme de la joiture. A prioris je ne souhaite pas identifier de manière unique un utilisateur avec un integer, mais avec une chaine de caractère hexadecimal de 32 charactère ( le résultat d'un md5) donc stocké dans un CHAR(32). Les performances des requetes avec jointures qui selectionnerons les informations de mes utilisateurs vont elles en être significativement affectées ? sous entendues les jointures sur des champs de type CHAR sont il beaucoup plus long que les jointures sur les champs de type INT.

Merci d'avance pour vos réponses.

**ozzmax** · 01/02/2006, 15h56

Pour ton numéro d'utilisateur c'est correct d'utiliser ton identifiant hexadicémal...
mais pour chacune de tes tables il est quand meme recommender de mettre des clé d'accès au enregistrement
c'est avec ces clé que tu devrais faire tes jointures

**pcaboche** · 01/02/2006, 16h06

Envoyé par yagogak

A prioris je ne souhaite pas identifier de manière unique un utilisateur avec un integer, mais avec une chaine de caractère hexadecimal de 32 charactère ( le résultat d'un md5)

Contradictoire ! Le MD5 ne permet pas d'identifier de manière unique deux enregistrements. C'est une "clef" au sens où elle permet de vérifier rapidement l'intégrité de données avec une marge d'erreur très faible (comme la clef à la fin d'un numéro de sécurité sociale, mais en beaucoup plus précis). Dans l'absolu, 2 enrgistrements différents peuvent avoir le même MD5 (si ça t'arrive, joue au loto, t'as plus de chances de gagner le gros lot).

Envoyé par yagogak

je dois stocké pour définir un utilisateur d'une application un nombre très important d'information, certaines de ces information seront solicitées très frequement alors que d'autres seront selectionnée que plus rarement.

il m'apparait donc evident d'éclater les données concernant les utilisateurs sur plusieurs table.( en tout 6 tables pour différents type de données, plus les jointures pour des données telles que les villes)

C'est quoi qui est très important? Le nombre d'utilisateurs ou leurs données personnelles? Quelle est la nature de ces données? Quelles sont les données de taille fixe et de taille variable? Quels données seront les plus sollicitées?

Il ne faut pas perdre de vue que les jointures prennent énormément de temps, alors faire des jointures de cardinalité 1,1 parce que certaines infos seront plus sollicitées que d'autre n'est pas, à priori, une bonne idée.

**yagogak** · 01/02/2006, 16h21

Contradictoire ! Le MD5 ne permet pas d'identifier de manière unique deux enregistrements. C'est une "clef" au sens où elle permet de vérifier rapidement l'intégrité de données avec une marge d'erreur très faible (comme la clef à la fin d'un numéro de sécurité sociale, mais en beaucoup plus précis). Dans l'absolu, 2 enrgistrements différents peuvent avoir le même MD5 (si ça t'arrive, joue au loto, t'as plus de chances de gagner le gros lot).

pour le loto j'y penserais, plus serieusement l'unicité de la chaine hexadécimal sera de toute façon assuré de mon coté à la création (au cas ou je gagne au loto)

C'est quoi qui est très important? Le nombre d'utilisateurs ou leurs données personnelles? Quelle est la nature de ces données? Quelles sont les données de taille fixe et de taille variable? Quels données seront les plus sollicitées?

Il ne faut pas perdre de vue que les jointures prennent énormément de temps, alors faire des jointures de cardinalité 1,1 parce que certaines infos seront plus sollicitées que d'autre n'est pas, à priori, une bonne idée.

le nombre d'utilisateurs : entre 400 et 1000
les données c'est en gros : 80 critères qui sont très variables de la date de creation du compte au nom, à la ville, l'adresse, le sexe etc ...

A partir de la table principale qui contiendra les informations vitale sur l'utilisateur ( login, pass et code unique hexa + 2 ou 3 broutille) j'ai besoin d'assuré ma relation 1:1 et la question est de savoir si le fait de le faire sur ce champ CHAR est judicieux ou non.

ou alors si'il vaut mieux effectuer les jointures sur un clé numérique, ou encore s'il il vaut mieux ne pas éclater les données sur autant de table et scinder uniquement en deux.

c'est simplement la volumétrie (qui n'est pas non plus délirante) de ce projet qui me fait me poser ces questions

**yagogak** · 01/02/2006, 16h23

Envoyé par ozzmax

Pour ton numéro d'utilisateur c'est correct d'utiliser ton identifiant hexadicémal...
mais pour chacune de tes tables il est quand meme recommender de mettre des clé d'accès au enregistrement
c'est avec ces clé que tu devrais faire tes jointures

donc tu serais d'avis d'avoir l'id HEXA uniqement sur la première table puis de faire les jointures sur une clé primaire qui elle sera de type INT c ça ?

**ozzmax** · 01/02/2006, 18h22

Oui c'est ca, l'id c'est un champs met le comme tu le souhaite dépendant de ce que tu recherches

Mais chaque table devrait avoir un clé primaire autoincrémente de type entier
tu les utilise pour les jointures c'est plus évident et logic je crois

**pcaboche** · 01/02/2006, 18h24

Ce n'est pas évident de répondre à toutes tes questions parce qu'on ne connais pas la finalité du code Hexa sur 32 caractères. J'imagine qu'il y en a une, mais tu ne nous dis pas laquelle.

Il est tout à fait possible de faire la jointure sur une chaine de caractères. Cepandant, question volumétrie, cela t'oblige à utiliser une chaîne de caractères comme clef étrangère dans chacune de tes tables, ce qui prend énormément de place.

Au niveau de tes tables maintenant. Ce qu'il faut savoir, c'est que si tous les champs d'une table sont de taille fixe, alors les enregistrements seront de taille fixe, ce qui accélèrera les recherches. Si en revanche au moins l'un des champs est de taille variable, alors les enregistrements seront de taille variable et on ne bénéficiera pas de cette optimisation. Premier point important: séparer les données de taille fixes des données de taille variables, de manière à accélérer les recherches sur les champs de taille fixe (c'est ce qui est fait d'ailleurs dans phpBB). (*)

Deuxième point important: il est intéressant de regrouper les données par domaines, afin de mieux s'y retrouver.

Troisième point important: tu peux éventuellement vouloir des champs NULL car tout le monde n'est pas concerné par cette information. Si tu as un faible pourcentage d'enregistrements concernés par un ensemble de champs (par exemple seulement 10%), alors tu peux mettre ces champs dans une table séparée et ainsi avoir une cardinalité 0,1 entre tes tables. C'est intéressant d'un point de vue volumétrie.

Quatrième point important: niveau volumétrie, il est préférable de faire des jointures avec des clefs de type INT plutôt qu'avec des clefs de type CHAR(32). Si tu as besoin de ton code hexa sur 32 caractères, met-le dans ta table principale (pour le retrouver facilement) et fait les jointures sur des champs de type INT.

Voilà.

---
(*) Note: selon ce principe, il est tout à fait justifié d'avoir une cardinalité 1,1 entre 2 tables, alors que c'est rigoureusement interdit lors de la phase d'analyse (au niveau du MCD de la méthode MERISE)

**Maximil ian** · 01/02/2006, 18h56

A lire également : discussion sur la qualité d'une clef

**pcaboche** · 01/02/2006, 19h06

Envoyé par Maximilian

A lire également : discussion sur la qualité d'une clef

Cela résume bien l'idée en effet. A un moment il prend l'exemple du numéro de sécurité sociale comme clef. Quand j'étais étudiant, notre prof de conception de Systèmes d'Information nous disait qu'il était interdit par la loi d'utiliser le numéro de sécu comme clef.

**yagogak** · 01/02/2006, 19h09

Envoyé par pcaboche

Quatrième point important: niveau volumétrie, il est préférable de faire des jointures avec des clefs de type INT plutôt qu'avec des clefs de type CHAR(32). Si tu as besoin de ton code hexa sur 32 caractères, met-le dans ta table principale (pour le retrouver facilement) et fait les jointures sur des champs de type INT.

j'ai ma réponse principale et tous vos autres commentaires vont m'aider à alimenter ma réfléxion notament sur les champs de taille fixe et variable.

merci pour vos réponses qui vont m'aider grandement.