bonjour
j'essaie de concevoir un mcd pour un site web.
Simplement je ne suis pas tres doué, j'apprends seul, et j'ai un peu trop l'habitude de créer les tables directement.
 
voici mon mcd actuel.

 
concernant le menu, il ne sera pas forcement rattaché à style, c'etait juste pour l'integrer au mcd actuel.
mon probleme c'est que je veux concevoir un menu avec recursivité à l'infini, meme si ça ne me sera pas forcement utile.
je me suis fait la réflexion qu'un menu est caractérisé par le couple (id du menu parent, position dans le menu parent).
je pense donc que je dois obtenir une clef primaire sur deux colonnes, sauf que d'apres ce que j'ai compris, il faut avoir une relation (0,n) (0,n) pour ça.
Pouvez-vous me débloquer ?
Avez-vous des conseils pour améliorer mon modèle ?
 
merci.

Je suis un peu étonné de voir une entité "menu". Et pourquoi pas une entité "bouton", une entité "fenêtre", une entité "liste déroulante". Ou bien il s'agit peut-être d'un catalogue, plutôt que d'un menu Windows.
 
L'intérêt essentiel d'un MCD est de préparer la création d'une base de données. Est-ce que le menu sera stocké dans la base ?
 
Bon, supposons qu'il ne s'agit pas du menu d'une interface graphique, mais d'un menu qui ressemble un catalogue, alors, que veut dire faire une association reflexive avec ce menu ? J'ai du mal à imaginer ce que cela peut-être, sauf peut-être si ce serait un catalogue qui pourrait contenir un sous-catalogue.

il s'agit d'un site web, et le menu d'un site web se retrouve généralement stocké dans la base. c'est plus pratique pour le mettre à jour que de l'écrire en dur dans un fichier php. apres si on associe une url au menu, on peut proposer un systeme d'edition de la page liée au menu dans une partie administration, etc...(tiens, ça rappelle pas un peu les cms ça...)
 
en faisant  
 
rapport_pere_fils
id_du_pere, pos_du_fils
#id_du_fils
 
menu
id_menu = #id_du_fils
libellé_du_menu
 
j'obtiens quelquechose de tout a fait potable.
par contre j'arrive pas a concevoir un MCD qui debouche là-dessus
A moins qu'on ait le droit d'avoir un couple d'identifiants dans le mcd, je suis paumé.

Soit t'as une dépendance fonctionnelle qui fait le lien parent/fils, soit ce qui est bien plus pratique et moins borné qu'alourdir pour respecter des normes qui valent ce qu'elle valent mais sont pas toujours justifiées, t'as une clé primaire sur l'ID et un attribut ID_père.
Id_père=0 c'est un père, sinon t'as un fils dont tu connais le père
 
Mais du coup pour récupérer tout ça faut utiliser une jointure sur la même table donc au final c'est pareil que d'en créer une pour faire le lien ,sauf que moins t'as de tables surtout pour des conneries mieux ça sera

en fait mon soucis principal est d'empecher la saisie de deux positions identiques pour un meme parent.
 
mes deux tables sont restrictible à :
menu
id_du_pere, pos_du_fils
libellé_du_menu
 
là où ça se complique et où ma scission en deux tables semblent devenir intéressante, c'est la fonctionnalité jukebox.
 
chanson
id_chanson
titre
durée extrait (peut etre mis là où sur chanson_playlist)
 
album
id_album
libellé_album
date_sortie
 
playlist
id_playlist
 
chanson_playlist
id_playlist, pos_playlist
#id_chanson
 
chanson_album
id_album, pos_album
#id_chanson
 
le probleme c'est que je fais ça à l'instinct. et des fois je suis à coté de la plaque. Je veux bien qu'a force d'en faire bcp je vais trouver seul un résultat correct rapidement, mais j'aimerais bien avoir une logique de travail en plus d'un "je le sens comme ça".

J'ai pas compris ce que tu appelles position. Et pour moi, c'est ce que je dit plus haut, tu lies le fils au père, pas l'inverse

position tel qu'affiché à l'écran
Forum 1                   Prix  5
HardWare.fr 2                 Se déconnecter 6
News  3                         Profil  7
Articles  4                      Aide 8
 
pos_playlist : position dans le fichier xml, m3u, asx, ..., sachant que le player va jouer les titre dans l'ordre dans lequel il les reçoit.
 
pos_album : numéro de plage dans l'album (track01, track02, track03, ....)
 
a vrai dire, à la base j'etais sur une simple clef primaire auto_increment avec une requete filtrant le parent et un ORDER BY dessus (la clef).
sauf qu'ajouter un menu pour le parent 'x' en 2eme position, dans le cas où on est deja au 4eme élément, je le vois soit comme "je trouve l'id du 2eme", j'update tous les enregistrements dont l'id est superieur ou égal à celle du 2eme (id= id+1), puis j'insere mon enregistrement avec l'ancien id du 2eme.
 
apres je me suis dit que ce serait bien d'avoir un champ position pour faire ce travail. j'ai créé un champ position, et j'en etais bien content, sauf que si on passe pas par mon formulaire, on peut specifier deux positions identiques, et je trouve pas ça propre.
 
j'ai préféré corriger ce probleme au niveau de la base de donnée, et refuser la saisie de deux valeurs identiques. c'est comme ça que j'en suis arrivé à ma clef sur deux colonnes. ainsi je ne modifie pas tous les identifiants supérieurs ou égal à id correspondant a toutes les catégories, mais uniquement les ids de la catégorie 'x'.
 
apres, c'est possible que je coupe les cheveux en 4. ma reflexion ne me semble pas particulierement utile pour un menu, car le nombre d'enregistrement n'est pas vraiment conséquent. le menu est surtout un exemple simple, une base de reflexion pour des trucs plus complexes.
 
edit: sorry j'a buggué

Clair que pour un menu...
T'as vraiment besoin de dynamique
Le lien père/fils ne modifie rien à la position si t'as un réel père

le dynamique, oui, j'en ai besoin.
Que ce soit pour le menu ou pour autre chose.
Je fais dans le site dynamique, pas statique.
Alors, maintenant que je maitrise mieux les requetes SQL et les bases de données, j'essaie d'optimiser mes requetes.
Et là que j'aide un pote sur un site imposant, j'essaie de lui fournir un vrai service, donc je prends la peine de faire un mcd, maintenant que je sais ce que c'est .
 
sinon, je ne saisis pas ta derniere phrase.
ma position est un nombre relatif au parent.
si je voulais faire ça relatif au "début" du menu, ça donnerait une serie de positions, séparées par des délimiteurs (points virgules par exemple), ce qui serait ingérable dans une requete. je ne peux pas mettre des champs a l'infini pour combler ce probleme. il me faut donc cette relativité.

NE pas tomber dans le tout dynamique Si ça change pas pas besoin de dynamique
 
Si t'arrive pas à comprendre que la position de ton père n'a rien à voir avec ses fils j'y peux rien...