Jusqu'à présent j'étais persuadée qu'une clé primaire était indispensable
dans une table, que sans elle il n'était pas possible de mettre en relation
les tables avec l'intégrité référencielle, que sans clé primaire l'assistant
formulaire ne pouvait pas créer des formulaires avec sous-formulaires etc...
Aujourd'hui je suis plongée dans le doute : quelqu'un ayant essayé de me
convaincre que la clé primaire ne servait à rien et qu'il suffisait qu'un
champ soit indexé sans doublon, j'ai fait des tests et ai constaté que tout
marche très bien sans clé primaire et avec à la place un champ indexé sans
doublon (exemple : numéro de client)....
Je me demande donc si c'est complètement équivalent d'avoir un champ clé
primaire ou un champ indexé sans doublon ou, (sachant que la clé primaire
est d'office indexée sans doublon et que ceci accélère recherches et tris),
s'il y a des raisons supplémentaires de préférer une clé primaire.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sylvain Lafontaine
Il s'agit plus ici d'une définition sémantique qu'autre chose: normalement, une clef primaire ne devrait plus changer de valeur une fois qu'elle a été allouée tandis que rien ne garantit que les valeurs indexées sans doublon ne changeront pas de valeur à tout moment. Les programmes clients reconnaissent automatiquement la clef primaire d'une table une fois celle-ci déterminée. Elle sera également automatiquement utilisée dans le cas de certaines clauses (DISTINCTROW) et opérations même si vous ne la sélectionner pas comme valeur à retourner; ce qui ne sera pas le cas des autres colonnes indexées sans doublons.
Bien entendu, avec Access, il est possible de changer la valeur d'une clef primaire mais là, on s'éloigne du standard original du language SQL.
Finalement, je ne sais pas pour Access mais avec SQL-Server, si vous définissez une clef primaire autre chose qu'un entier, SQL-Server attribue quand même à l'interne une valeur entière unique à stocker comme identifiant de rangée dans les indexes; alors vous ne sauvez pas grand chose de ce côté-là.
Il y a également la question que les valeurs de clefs primaires ne doivent pas être nulles.
-- Sylvain Lafontaine, ing. MVP - Technologies Virtual-PC E-mail: http://cerbermail.com/?QugbLEWINF
"Marie" wrote in message news:44f87475$0$21145$
Bonjour,
Jusqu'à présent j'étais persuadée qu'une clé primaire était indispensable dans une table, que sans elle il n'était pas possible de mettre en relation les tables avec l'intégrité référencielle, que sans clé primaire l'assistant formulaire ne pouvait pas créer des formulaires avec sous-formulaires etc... Aujourd'hui je suis plongée dans le doute : quelqu'un ayant essayé de me convaincre que la clé primaire ne servait à rien et qu'il suffisait qu'un champ soit indexé sans doublon, j'ai fait des tests et ai constaté que tout marche très bien sans clé primaire et avec à la place un champ indexé sans doublon (exemple : numéro de client)....
Je me demande donc si c'est complètement équivalent d'avoir un champ clé primaire ou un champ indexé sans doublon ou, (sachant que la clé primaire est d'office indexée sans doublon et que ceci accélère recherches et tris), s'il y a des raisons supplémentaires de préférer une clé primaire.
Merci de m'éclairer, Marie
Il s'agit plus ici d'une définition sémantique qu'autre chose: normalement,
une clef primaire ne devrait plus changer de valeur une fois qu'elle a été
allouée tandis que rien ne garantit que les valeurs indexées sans doublon ne
changeront pas de valeur à tout moment. Les programmes clients
reconnaissent automatiquement la clef primaire d'une table une fois celle-ci
déterminée. Elle sera également automatiquement utilisée dans le cas de
certaines clauses (DISTINCTROW) et opérations même si vous ne la
sélectionner pas comme valeur à retourner; ce qui ne sera pas le cas des
autres colonnes indexées sans doublons.
Bien entendu, avec Access, il est possible de changer la valeur d'une clef
primaire mais là, on s'éloigne du standard original du language SQL.
Finalement, je ne sais pas pour Access mais avec SQL-Server, si vous
définissez une clef primaire autre chose qu'un entier, SQL-Server attribue
quand même à l'interne une valeur entière unique à stocker comme identifiant
de rangée dans les indexes; alors vous ne sauvez pas grand chose de ce
côté-là.
Il y a également la question que les valeurs de clefs primaires ne doivent
pas être nulles.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF
"Marie" <maremy@club-internet.fr> wrote in message
news:44f87475$0$21145$7a628cd7@news.club-internet.fr...
Bonjour,
Jusqu'à présent j'étais persuadée qu'une clé primaire était indispensable
dans une table, que sans elle il n'était pas possible de mettre en
relation les tables avec l'intégrité référencielle, que sans clé primaire
l'assistant formulaire ne pouvait pas créer des formulaires avec
sous-formulaires etc...
Aujourd'hui je suis plongée dans le doute : quelqu'un ayant essayé de me
convaincre que la clé primaire ne servait à rien et qu'il suffisait qu'un
champ soit indexé sans doublon, j'ai fait des tests et ai constaté que
tout marche très bien sans clé primaire et avec à la place un champ indexé
sans doublon (exemple : numéro de client)....
Je me demande donc si c'est complètement équivalent d'avoir un champ clé
primaire ou un champ indexé sans doublon ou, (sachant que la clé primaire
est d'office indexée sans doublon et que ceci accélère recherches et
tris), s'il y a des raisons supplémentaires de préférer une clé primaire.
Il s'agit plus ici d'une définition sémantique qu'autre chose: normalement, une clef primaire ne devrait plus changer de valeur une fois qu'elle a été allouée tandis que rien ne garantit que les valeurs indexées sans doublon ne changeront pas de valeur à tout moment. Les programmes clients reconnaissent automatiquement la clef primaire d'une table une fois celle-ci déterminée. Elle sera également automatiquement utilisée dans le cas de certaines clauses (DISTINCTROW) et opérations même si vous ne la sélectionner pas comme valeur à retourner; ce qui ne sera pas le cas des autres colonnes indexées sans doublons.
Bien entendu, avec Access, il est possible de changer la valeur d'une clef primaire mais là, on s'éloigne du standard original du language SQL.
Finalement, je ne sais pas pour Access mais avec SQL-Server, si vous définissez une clef primaire autre chose qu'un entier, SQL-Server attribue quand même à l'interne une valeur entière unique à stocker comme identifiant de rangée dans les indexes; alors vous ne sauvez pas grand chose de ce côté-là.
Il y a également la question que les valeurs de clefs primaires ne doivent pas être nulles.
-- Sylvain Lafontaine, ing. MVP - Technologies Virtual-PC E-mail: http://cerbermail.com/?QugbLEWINF
"Marie" wrote in message news:44f87475$0$21145$
Bonjour,
Jusqu'à présent j'étais persuadée qu'une clé primaire était indispensable dans une table, que sans elle il n'était pas possible de mettre en relation les tables avec l'intégrité référencielle, que sans clé primaire l'assistant formulaire ne pouvait pas créer des formulaires avec sous-formulaires etc... Aujourd'hui je suis plongée dans le doute : quelqu'un ayant essayé de me convaincre que la clé primaire ne servait à rien et qu'il suffisait qu'un champ soit indexé sans doublon, j'ai fait des tests et ai constaté que tout marche très bien sans clé primaire et avec à la place un champ indexé sans doublon (exemple : numéro de client)....
Je me demande donc si c'est complètement équivalent d'avoir un champ clé primaire ou un champ indexé sans doublon ou, (sachant que la clé primaire est d'office indexée sans doublon et que ceci accélère recherches et tris), s'il y a des raisons supplémentaires de préférer une clé primaire.
