Pour mon forum, je vais opter pour deux tables. Une pour les thread, et l'aute pour les reponses....
La table question : thread | date | auteur | titre | message
et la table reponse : thread | date | auteur | message
visiblement il n'y a pas de clé unique... pas glop :-(
Maintenant, dans la page principale de mon forum, j'aimerais afficher un tableau contenant les infos suivantes :
thread | date | auteur | titre | date dern. reponse | auteur dern. reponse
ça dépend du sgbd
-- P'tit Marcel
Christophe Lephay
"P'tit Marcel" a écrit dans le message de news:
Niko écrivit: > La table question : > thread | date | auteur | titre | message > > et la table reponse : > thread | date | auteur | message
visiblement il n'y a pas de clé unique... pas glop :-(
pourquoi ?
(j'imagine que thread est la clé dans la table question).
de mon coté, j'ai rarement vu un interet dans le fait de mettre une clé primaire dans une table qui n'est source d'aucune relation (les seuls cas étant quand certaines requêtes peuvent nécessiter des jointures reflexives)...
Chris
"P'tit Marcel" <geononauxspams@centrale-lyon.org.invalid> a écrit dans le
message de news:Xns93B3C2AA4DBE6bulgroz7@213.228.0.32...
Niko écrivit:
> La table question :
> thread | date | auteur | titre | message
>
> et la table reponse :
> thread | date | auteur | message
visiblement il n'y a pas de clé unique... pas glop :-(
pourquoi ?
(j'imagine que thread est la clé dans la table question).
de mon coté, j'ai rarement vu un interet dans le fait de mettre une clé
primaire dans une table qui n'est source d'aucune relation (les seuls cas
étant quand certaines requêtes peuvent nécessiter des jointures
reflexives)...
Niko écrivit: > La table question : > thread | date | auteur | titre | message > > et la table reponse : > thread | date | auteur | message
visiblement il n'y a pas de clé unique... pas glop :-(
pourquoi ?
(j'imagine que thread est la clé dans la table question).
de mon coté, j'ai rarement vu un interet dans le fait de mettre une clé primaire dans une table qui n'est source d'aucune relation (les seuls cas étant quand certaines requêtes peuvent nécessiter des jointures reflexives)...
Chris
P'tit Marcel
Christophe Lephay écrivit:
"P'tit Marcel" a écrit dans le message de news:
Niko écrivit: > La table question : > thread | date | auteur | titre | message > > et la table reponse : > thread | date | auteur | message
visiblement il n'y a pas de clé unique... pas glop :-(
pourquoi ?
(j'imagine que thread est la clé dans la table question).
de mon coté, j'ai rarement vu un interet dans le fait de mettre une clé primaire dans une table qui n'est source d'aucune relation
parce qu'une clé unique permet d'identifier de façon certaine une ligne de la table. Sans elle il est difficile (voire impossible) de supprimer ou modifier une ligne sans risque de toucher d'autres lignes. Par ailleurs, une clé unique permet d'établir des jointures ou des select imbriqués un peu compliqués.
-- P'tit Marcel
Christophe Lephay écrivit:
"P'tit Marcel" <geononauxspams@centrale-lyon.org.invalid> a écrit dans le
message de news:Xns93B3C2AA4DBE6bulgroz7@213.228.0.32...
Niko écrivit:
> La table question :
> thread | date | auteur | titre | message
>
> et la table reponse :
> thread | date | auteur | message
visiblement il n'y a pas de clé unique... pas glop :-(
pourquoi ?
(j'imagine que thread est la clé dans la table question).
de mon coté, j'ai rarement vu un interet dans le fait de mettre une clé
primaire dans une table qui n'est source d'aucune relation
parce qu'une clé unique permet d'identifier de façon certaine une ligne de
la table. Sans elle il est difficile (voire impossible) de supprimer ou
modifier une ligne sans risque de toucher d'autres lignes. Par ailleurs,
une clé unique permet d'établir des jointures ou des select imbriqués un
peu compliqués.
Niko écrivit: > La table question : > thread | date | auteur | titre | message > > et la table reponse : > thread | date | auteur | message
visiblement il n'y a pas de clé unique... pas glop :-(
pourquoi ?
(j'imagine que thread est la clé dans la table question).
de mon coté, j'ai rarement vu un interet dans le fait de mettre une clé primaire dans une table qui n'est source d'aucune relation
parce qu'une clé unique permet d'identifier de façon certaine une ligne de la table. Sans elle il est difficile (voire impossible) de supprimer ou modifier une ligne sans risque de toucher d'autres lignes. Par ailleurs, une clé unique permet d'établir des jointures ou des select imbriqués un peu compliqués.
