sachant que producteurs et/ou chanteurs peuvent contenir X contacts (là
est la difficulté).
Et qu'il faudra pouvoir trouver par exemple tous les morceaux dont un
producteur s'appelle toto ou dont le chanteur s'appelle titi.
Comment structureriez la base pour que la requête soit la moins "lourde"
possible ? je m'interroge surtout sur les liens et la manière de les
stocker :
exemple : un morceau dont les producteurs sont les id 1,4,19 de la table
contact et le chanteur l'id 100 de la table contact.
Je t'arrête tout de suite. Un attribut se doit d'être atomique, donc "producteur*s*" et "chanteur*s*" ne _peuvent pas_ être des attributs de l'entité "morceau" (voir plus bas).
- fiche personne : nom, prénom, adresse...
sachant que producteurs et/ou chanteurs peuvent contenir X contacts (là est la difficulté).
Il n'y a aucune difficulté, à condition de penser dans les bon termes. Ne pense pas en termes de "fiches" (une fiche, c'est une élément de l'interface utilisateur, pas un élément d'une base relationnelle), pense en termes d'entités, de relations et d'attributs.
Et qu'il faudra pouvoir trouver par exemple tous les morceaux dont un producteur s'appelle toto ou dont le chanteur s'appelle titi.
Ici, il y a une entité que tu n'a pas clairement identifié, celle de "rôle" (ie : "producteur", "chanteur" etc... )
Si tu pose ça sous forme de règles, c'est plus simple:
1. un morceau est défini par un titre, une année, .... 2. une personne est définie par un nom, un prenom, .... 3. un role est défini par un libellé 4. une ou plusieurs personnes jouent un ou plusieur roles sur un ou plusieurs morceaux 5. une même personne ne peut pas jouer plusieurs fois le même rôle sur le même morceau
La structure de ta base est complètement définie par ces 5 règles.
Comment structureriez la base pour que la requête soit la moins "lourde" possible ?
Commence donc par faire les choses dans les formes (normales en l'occurrence), tu verra après s'il y a un problème de performances, et si oui comment le résoudre au mieux.
je m'interroge surtout sur les liens et la manière de les stocker :
règles 4. et 5.
Autrement dit, avec une table qui dit le rôle que joue une personne sur un morceau (donc une clé étrangère sur morceaux, une clé étrangère sur personnes, et une clé étrangère sur rôles).
Allez, un exemple (simplifié):
# règle 1 create table morceaux( id integer not null primary key, titre varchar(255) not null );
# règle 2 create table personnes( id integer not null primary key, nom varchar(100) not null );
# règle 3 create table roles( id integer not null primary key, libelle varchar(50) );
# règle 4 create table participations( id_morceau integer not null foreign key references morceaux.id, id_personne integer not null foreign key references personnes.id, id_role integer not null foreign key references roles.id,
insert into roles(id, libelle) values(1, "producteur"); insert into roles(id, libelle) values(2, "chanteur");
insert into personnes(id, nom) values(1, "titi"); insert into personnes(id, nom) values(2, "toto");
insert into morceaux(id, titre) values(1, "lalala"); insert into morceaux(id, titre) values(2, "oh oh");
# titi chante lalala insert into participations(id_morceau, id_personne, id_role) values(1, 1, 2);
# toto produit lalala insert into participations(id_morceau, id_personne, id_role) values(1, 2, 1);
# titi produit et chante ho ho insert into participations(id_morceau, id_personne, id_role) values(2, 1, 1); insert into participations(id_morceau, id_personne, id_role) values(2, 1, 2);
# Et pour ce qui est de ta question: "trouver par exemple tous les # morceaux dont un producteur s'appelle toto ou dont le chanteur # s'appelle titi.", ça donne, littéralement :
select m.id, m.titre, pe.nom, r.libelle from morceaux m inner join participations pa on m.id=pa.id_morceau inner join personnes pe on pe.id=pa.id_personne inner join roles r on r.id=pa.id_role where (r.libelle="producteur" and pe.nom="toto") or (r.libelle="chanteur" and pe.nom="titi");
+----+--------+------+------------+ | id | titre | nom | libelle | +----+--------+------+------------+ | 1 | lalala | titi | chanteur | | 1 | lalala | toto | producteur | | 2 | oh oh | titi | chanteur | +----+--------+------+------------+
Voili voilà... HTH
Anthony a écrit :
bonjour,
j'imagine une base mysql avec la structure suivante :
- table morceaux
- table personnes
Avec un lien entre morceaux et personnes, sachant que les tables peuvent
être liées de façon complexe :
Je t'arrête tout de suite. Un attribut se doit d'être atomique, donc
"producteur*s*" et "chanteur*s*" ne _peuvent pas_ être des attributs de
l'entité "morceau" (voir plus bas).
- fiche personne : nom, prénom, adresse...
sachant que producteurs et/ou chanteurs peuvent contenir X contacts (là
est la difficulté).
Il n'y a aucune difficulté, à condition de penser dans les bon termes.
Ne pense pas en termes de "fiches" (une fiche, c'est une élément de
l'interface utilisateur, pas un élément d'une base relationnelle), pense
en termes d'entités, de relations et d'attributs.
Et qu'il faudra pouvoir trouver par exemple tous les morceaux dont un
producteur s'appelle toto ou dont le chanteur s'appelle titi.
Ici, il y a une entité que tu n'a pas clairement identifié, celle de
"rôle" (ie : "producteur", "chanteur" etc... )
Si tu pose ça sous forme de règles, c'est plus simple:
1. un morceau est défini par un titre, une année, ....
2. une personne est définie par un nom, un prenom, ....
3. un role est défini par un libellé
4. une ou plusieurs personnes jouent un ou plusieur roles sur un ou
plusieurs morceaux
5. une même personne ne peut pas jouer plusieurs fois le même rôle sur
le même morceau
La structure de ta base est complètement définie par ces 5 règles.
Comment structureriez la base pour que la requête soit la moins "lourde"
possible ?
Commence donc par faire les choses dans les formes (normales en
l'occurrence), tu verra après s'il y a un problème de performances, et
si oui comment le résoudre au mieux.
je m'interroge surtout sur les liens et la manière de les
stocker :
règles 4. et 5.
Autrement dit, avec une table qui dit le rôle que joue une personne sur
un morceau (donc une clé étrangère sur morceaux, une clé étrangère sur
personnes, et une clé étrangère sur rôles).
Allez, un exemple (simplifié):
# règle 1
create table morceaux(
id integer not null primary key,
titre varchar(255) not null
);
# règle 2
create table personnes(
id integer not null primary key,
nom varchar(100) not null
);
# règle 3
create table roles(
id integer not null primary key,
libelle varchar(50)
);
# règle 4
create table participations(
id_morceau integer not null foreign key references morceaux.id,
id_personne integer not null foreign key references personnes.id,
id_role integer not null foreign key references roles.id,
insert into roles(id, libelle) values(1, "producteur");
insert into roles(id, libelle) values(2, "chanteur");
insert into personnes(id, nom) values(1, "titi");
insert into personnes(id, nom) values(2, "toto");
insert into morceaux(id, titre) values(1, "lalala");
insert into morceaux(id, titre) values(2, "oh oh");
# titi chante lalala
insert into participations(id_morceau, id_personne, id_role) values(1,
1, 2);
# toto produit lalala
insert into participations(id_morceau, id_personne, id_role) values(1,
2, 1);
# titi produit et chante ho ho
insert into participations(id_morceau, id_personne, id_role) values(2,
1, 1);
insert into participations(id_morceau, id_personne, id_role) values(2,
1, 2);
# Et pour ce qui est de ta question: "trouver par exemple tous les
# morceaux dont un producteur s'appelle toto ou dont le chanteur
# s'appelle titi.", ça donne, littéralement :
select
m.id, m.titre, pe.nom, r.libelle
from morceaux m
inner join participations pa on m.id=pa.id_morceau
inner join personnes pe on pe.id=pa.id_personne
inner join roles r on r.id=pa.id_role
where
(r.libelle="producteur" and pe.nom="toto")
or
(r.libelle="chanteur" and pe.nom="titi");
+----+--------+------+------------+
| id | titre | nom | libelle |
+----+--------+------+------------+
| 1 | lalala | titi | chanteur |
| 1 | lalala | toto | producteur |
| 2 | oh oh | titi | chanteur |
+----+--------+------+------------+
Je t'arrête tout de suite. Un attribut se doit d'être atomique, donc "producteur*s*" et "chanteur*s*" ne _peuvent pas_ être des attributs de l'entité "morceau" (voir plus bas).
- fiche personne : nom, prénom, adresse...
sachant que producteurs et/ou chanteurs peuvent contenir X contacts (là est la difficulté).
Il n'y a aucune difficulté, à condition de penser dans les bon termes. Ne pense pas en termes de "fiches" (une fiche, c'est une élément de l'interface utilisateur, pas un élément d'une base relationnelle), pense en termes d'entités, de relations et d'attributs.
Et qu'il faudra pouvoir trouver par exemple tous les morceaux dont un producteur s'appelle toto ou dont le chanteur s'appelle titi.
Ici, il y a une entité que tu n'a pas clairement identifié, celle de "rôle" (ie : "producteur", "chanteur" etc... )
Si tu pose ça sous forme de règles, c'est plus simple:
1. un morceau est défini par un titre, une année, .... 2. une personne est définie par un nom, un prenom, .... 3. un role est défini par un libellé 4. une ou plusieurs personnes jouent un ou plusieur roles sur un ou plusieurs morceaux 5. une même personne ne peut pas jouer plusieurs fois le même rôle sur le même morceau
La structure de ta base est complètement définie par ces 5 règles.
Comment structureriez la base pour que la requête soit la moins "lourde" possible ?
Commence donc par faire les choses dans les formes (normales en l'occurrence), tu verra après s'il y a un problème de performances, et si oui comment le résoudre au mieux.
je m'interroge surtout sur les liens et la manière de les stocker :
règles 4. et 5.
Autrement dit, avec une table qui dit le rôle que joue une personne sur un morceau (donc une clé étrangère sur morceaux, une clé étrangère sur personnes, et une clé étrangère sur rôles).
Allez, un exemple (simplifié):
# règle 1 create table morceaux( id integer not null primary key, titre varchar(255) not null );
# règle 2 create table personnes( id integer not null primary key, nom varchar(100) not null );
# règle 3 create table roles( id integer not null primary key, libelle varchar(50) );
# règle 4 create table participations( id_morceau integer not null foreign key references morceaux.id, id_personne integer not null foreign key references personnes.id, id_role integer not null foreign key references roles.id,
insert into roles(id, libelle) values(1, "producteur"); insert into roles(id, libelle) values(2, "chanteur");
insert into personnes(id, nom) values(1, "titi"); insert into personnes(id, nom) values(2, "toto");
insert into morceaux(id, titre) values(1, "lalala"); insert into morceaux(id, titre) values(2, "oh oh");
# titi chante lalala insert into participations(id_morceau, id_personne, id_role) values(1, 1, 2);
# toto produit lalala insert into participations(id_morceau, id_personne, id_role) values(1, 2, 1);
# titi produit et chante ho ho insert into participations(id_morceau, id_personne, id_role) values(2, 1, 1); insert into participations(id_morceau, id_personne, id_role) values(2, 1, 2);
# Et pour ce qui est de ta question: "trouver par exemple tous les # morceaux dont un producteur s'appelle toto ou dont le chanteur # s'appelle titi.", ça donne, littéralement :
select m.id, m.titre, pe.nom, r.libelle from morceaux m inner join participations pa on m.id=pa.id_morceau inner join personnes pe on pe.id=pa.id_personne inner join roles r on r.id=pa.id_role where (r.libelle="producteur" and pe.nom="toto") or (r.libelle="chanteur" and pe.nom="titi");
+----+--------+------+------------+ | id | titre | nom | libelle | +----+--------+------+------------+ | 1 | lalala | titi | chanteur | | 1 | lalala | toto | producteur | | 2 | oh oh | titi | chanteur | +----+--------+------+------------+
Voili voilà... HTH
Anthony
Bruno Desthuilliers a écrit :
Il n'y a aucune difficulté, à condition de penser dans les bon termes. Ne pense pas en termes de "fiches" (une fiche, c'est une élément de l'interface utilisateur, pas un élément d'une base relationnelle), pense en termes d'entités, de relations et d'attributs.
un très grand merci... une solution des plus didactique. un regard extérieur et tout change...
cordialement,
Anthony
Bruno Desthuilliers a écrit :
Il n'y a aucune difficulté, à condition de penser dans les bon termes.
Ne pense pas en termes de "fiches" (une fiche, c'est une élément de
l'interface utilisateur, pas un élément d'une base relationnelle), pense
en termes d'entités, de relations et d'attributs.
un très grand merci... une solution des plus didactique.
un regard extérieur et tout change...
Il n'y a aucune difficulté, à condition de penser dans les bon termes. Ne pense pas en termes de "fiches" (une fiche, c'est une élément de l'interface utilisateur, pas un élément d'une base relationnelle), pense en termes d'entités, de relations et d'attributs.
un très grand merci... une solution des plus didactique. un regard extérieur et tout change...
cordialement,
Anthony
Alain Montfranc
Bruno Desthuilliers a formulé la demande :
Anthony a écrit :
bonjour,
j'imagine une base mysql avec la structure suivante : - table morceaux - table personnes
Avec un lien entre morceaux et personnes, sachant que les tables peuvent être liées de façon complexe :
Je t'arrête tout de suite. Un attribut se doit d'être atomique, donc
Et le multivalué, hein, vous en faites quoi du multivalué ?
:-D
PS: helios60 s'en encore fait jeter de wikipedia !
N'invoquez _jamais_ le diable !
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 17-11-2009, ? propos de
Re: structure mysql et requête complexe.,
Alain Montfranc ?crivait dans fr.comp.applications.sgbd :
Bruno Desthuilliers a formulé la demande :
Anthony a écrit :
bonjour,
j'imagine une base mysql avec la structure suivante :
- table morceaux
- table personnes
Avec un lien entre morceaux et personnes, sachant que les tables peuvent
être liées de façon complexe :
Je t'arrête tout de suite. Un attribut se doit d'être atomique, donc
Et le multivalué, hein, vous en faites quoi du multivalué ?
:-D
PS: helios60 s'en encore fait jeter de wikipedia !
N'invoquez _jamais_ le diable !
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Je t'arrête tout de suite. Un attribut se doit d'être atomique, donc
Et le multivalué, hein, vous en faites quoi du multivalué ?
:-D
PS: helios60 s'en encore fait jeter de wikipedia !
N'invoquez _jamais_ le diable !
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
helios
Alain Montfranc a écrit :
Bruno Desthuilliers a formulé la demande :
Anthony a écrit :
bonjour,
j'imagine une base mysql avec la structure suivante : - table morceaux - table personnes
Avec un lien entre morceaux et personnes, sachant que les tables peuvent être liées de façon complexe :
Je t'arrête tout de suite. Un attribut se doit d'être atomique, donc
Et le multivalué, hein, vous en faites quoi du multivalué ?
:-D
PS: helios60 s'en encore fait jeter de wikipedia !
le PS est de la diffamation et si j'étais aussi procédurier qu'un certain Homo qui fréquente ce forum je vous assignerais pour cela
http://cjoint.com/data/lrmTLzVMbc.htm
et alors quand c'est vrai c'est aussi de la diffamation :
la médisance est de la diffamation vrai la calomnie est de la diffamation fausse
la justice ne connait que la diffamation vrai ou fausse ne change rien aux fait de diffamation
Alain Montfranc
Bruno Desthuilliers a exposé le 17/11/2009 :
Alain Montfranc a écrit :
Bruno Desthuilliers a formulé la demande :
Je t'arrête tout de suite. Un attribut se doit d'être atomique, donc
Et le multiva
Ah, non, shut, malheureux, ne dit pas ce mot, NON, NE LE DIT PAAAAAAS !!!!!!
> lué, hein, vous en faites quoi du multivalué ?
Et merdre, trop tard :(
Ceci dit le multivalué zimboum truc chouette se remplace aisément par l'ajout de tables intermédiaires dans des systèmes plus répandus, normalisés, mieux testés et probablement plus fiables.
Bruno Desthuilliers a exposé le 17/11/2009 :
Alain Montfranc a écrit :
Bruno Desthuilliers a formulé la demande :
Je t'arrête tout de suite. Un attribut se doit d'être atomique, donc
Et le multiva
Ah, non, shut, malheureux, ne dit pas ce mot, NON, NE LE DIT PAAAAAAS !!!!!!
> lué, hein, vous en faites quoi du multivalué ?
Et merdre, trop tard :(
Ceci dit le multivalué zimboum truc chouette se remplace aisément par
l'ajout de tables intermédiaires dans des systèmes plus répandus,
normalisés, mieux testés et probablement plus fiables.
Je t'arrête tout de suite. Un attribut se doit d'être atomique, donc
Et le multiva
Ah, non, shut, malheureux, ne dit pas ce mot, NON, NE LE DIT PAAAAAAS !!!!!!
> lué, hein, vous en faites quoi du multivalué ?
Et merdre, trop tard :(
Ceci dit le multivalué zimboum truc chouette se remplace aisément par l'ajout de tables intermédiaires dans des systèmes plus répandus, normalisés, mieux testés et probablement plus fiables.
