3
??????
Desole je comprends pas ton intervention.
Je vais le dire en français. desole pour les autres
Cette table n'est la que pour faire la relation entre le group et les user. C'est betement une table de relation ce que l'on fait classiquement en relationnel. Elle n'a besoin que et uniquement des cles primaires des deux tables qu'elle met en relation.
=> linkid ne sert a rien fonctionnellement (c-a-d en terme de logique metier et meme de souplesse???) et techniquement, il prend de la place pour rien, et en plus ne force pas l'unicite des donnees (ce qui est dommage).
Et je vois pas en quoi ajouter un index primaire autoincrement sur ce genre de table de relation ajoute de la souplesse et de l'evolutivite...
Il me semble pas avoir dit qu'il ne fallait jamais utilise ce genre d'index autoincrement... (qu'on appelait cle techniques de mon temps qui sont justement tres pratique dans ce genre de table de relation car du coup on a que 2 champs si on avait du coller le nom, surnom etc... du user pfuuut)
Donc desole je comprend pas ton intervention... et j'ai beau relire mon intervention precedente je vois pas ce que me vaut cette intervention... et cela meme si je suis pas super bon en anglais.
Et perso j'adore les bases de donnees... je suis plus specialiste Oracle (de la version 5.0 a 8i apres bcq moins) que MySQL, et le relationnel (dans les bases

) ca a longtemps ete mon dada voir meme ma specialite

.
Quand a la rapidite... plus tu auras de donnees et plus l'interet d'une base de donnees sera importante. Si tu as 5 donnee a gerer utilise un fichier plat c'est sur que cela sera plus rapide, si tu en as des tonnes y a pas photo prend une base de donnees (et si tu en as vraiment vraiment bcq y a des moteurs plus performants que d'autre...)
English Google Translation of the above:
Quote:
Sorry I do not understand your response.
I'll say it in French. sorry for the other
This table is only to make the relationship between the group and the user. It is foolishly a relationship table that is conventionally done in relationships. She does not need that and only primary keys of the two tables it links.
=> Linkid is useless functionally (ie in terms of logical profession and even flexibility??) And technically, it takes up space for nothing more and does not force the uniqueness of the data (which is a shame ).
And I do not see how to add a autoincrement primary index on this kind of relationship table adds flexibility and scalability ...
It seems to me not saying that you should never use this kind of index autoincrement ... (called key techniques that my time is just very handy in this type of relationship table becuase it has 2 fields if we had the paste name, nickname etc ... the user pfuuut)
So sorry I do not understand your response ... and I'm reading my previous response I do not see that this intervention is me ... and this even though I'm not super good at English.
And personally I love databases ... I am more specialist Oracle (version 8i after a 5.0 bcq less) than MySQL, and relational (in bases) ca has long been my hobby even see my specialty.
When was the rapidity ... get more and more data of the interest of a database is important. If you manage a given 5 uses a flat file that is on it will be faster if you have tons of picture taking is not a database (and if you have really really bcq engines are more efficient than other ...)