Citation:
Envoyé par
NLS le pingouin
En fait, je sépare les magazine de leurs différents numéros (Issue).
OK. Je n'avais pas compris ça comme ça, pas habitué à modéliser en anglais.
Tu as donc raison de vouloir faire ainsi.
Citation:
Mais je trouve aussi que ma table "From_issue" est assez maladroitement construite, il faudra que je me penche un peu plus dessus.
Paper(id, titre) -0,n --- From_issue(n°, date) --- 0,1 - Zine(nom)
Je dirais plutôt ceci :
Paper(id, titre) -0,n --- From_issue(n°, date) --- 1,1 - Zine(nom)
Un numéro est forcément celui d'un magazine. D'ailleurs, encore une meilleure solution serait de faire une identification relative :
Paper(id, titre) -0,n --- From_issue(n°, date) --- (1,1) - Zine(nom)
Ce qui fait que la clé étrangère référençant le Zine participe à la clé primaire de la table associative From_issue.
From_issue (fi_id_zine, fi_numero, fi_date)
Citation:
Ceci, et le risque d'homonyme, m'ont fait mettre un ID sur la table des auteurs.
Au niveau des organisations, l'homonymie me semblait quand même moins fréquente. J'ai donc préféré mettre le nom comme clef principale.
Une clé en VARCHAR est une mauvaise clé. Ajoute un identifiant auto-incrémenté à toute table issue d'une entité type du MCD, sauf en cas d'héritage ou d'identification relative.
Citation:
Dans cette requête, je n'ai besoin que du nom des Organisations responsables de la publication, et non des autres informations stockées dans la table Org. C'est pourquoi je fais la jointure uniquement sur l'association Published_fro_org qui me fournit la donnée dont j'ai besoin.
Et pourtant, dans ta requête, tu faisais bien la jointure vers la table Org !
Citation:
Sinon, ta requête fonctionne très bien. Je n'ai plus qu'à en étudier le fonctionnement. Je te remercie de ta réponse, elle m'aide bien à avancer.
Je suis des cours de SQL à la fac, je suis obligé de travailler par moi-même pour espérer avoir un niveau correct à la fin de l'année sinon ça n'avancerait pas.
Tu trouveras dans nos forums, sites, tutoriels et blogs, toute l'aide nécessaire.
Citation:
Si tu as des insultes à propos de la conception de ma base de donnée, n'hésite pas. J'ai passé pas mal de temps dessus, mais le seul moyen que j'ai de valider la conception c'est de tenter de l'intégrer dans un système d'information pour voir là où ça casse.
Pour la conception de la BDD, tu peux proposer ton modèle dans le forum Schéma si tu as fait un MCD ou un MLD ou schéma équivalent ou alors dans le forum Diagrammes de classes si tu as utilisé UML.
Pour le moment, je ne vois pas d'énormités dans ton schéma, à part les petites remarques que j'ai déjà faites.
Citation:
Edit :
Au passage, autre question. Les données extraites par cette requête seront traitées par du php pour les placer dans un tableau html.
J'ai prévu de formater en partie certains de ces éléments à coups de CONCAT et autre. Par exemple, les auteurs auront un lien hypertext vers une page donnant plus d'informations à leur sujet. Le fait de créer ce lien dans la requète est-il une absurdité ?
Je pensais faire comme ça pour pouvoir traiter une ligne à la fois, chaque ligne concernant un article précis.
Ce n'est pas une absurdité mais si le volume de données s'accroit, tu risques de finir par voir les performances se dégrader parce que le regroupement est plus gourmand donc plus long qu'un simple SELECT.
À noter quand même que GROUP_CONCAT n'est pas du standard SQL mais du spécifique à MySQL.
MySQL n'est pas le meilleur choix pour apprendre à bien faire les choses car il est trop permissif sur certains points, ce qui peut entraîner des erreurs, et trop limité sur d'autres, ce qui oblige à faire des requêtes plus complexes que nécessaire ou des procédures au lieu d'instructions SQL plus simples.
En Open source, Postgresql est bien meilleur !