Moi et un de mes amis sommes en création d'un site web en php. Nous allons avoir des menus dynamiques. Je commence pour vous énoncer la facon dont je voyais les choses:
 
Nous aurious 2 tables: une pour les menus et une pour les éléments de menu
 
Menu: ID, Title, Position, Visible
SubMenu: ID, MenuID, Position, Action, Visible
 
De son coté, mon ami croit qu'il serait mieux de regrouper les deux tables en une seule de cette facon:
 
Menu: ID, RecursiveID, Position, Action, Visible
 
De cette facon, pour créer un menu, nous aurions 0 dans RecursiveID. Si l'on veut ajouter des éléments dans le menu ayant l'ID 1, on attribut la valeur de 1 au RecursiveID de l'élément de menu. Et lorsque l'on désirerait une sous-élement, par exemple pour mon élement ayant l'ID 4, bien on placerait 4 dans le champs RecursiveID
 
Quel est la meilleur méthode selon vous? D'un coté la sienne nous permet d'utilisé 1 table au lieu de deux, mais c mélanger des choses qui se ressemble mais qui ne sont pas pareil(ma vision des choses, c'est comme si on aurait la meme table pour les client d'un magasin et ses employés)

le modèle de ton ami est meileur    
les données stockées sont identiques alors pourquoi avoir 2 tables pour cela ? (ca constitue une surcharge)

 
bin en réalité, le menu aura jamais d'action
 
comme dans mon exemple de regrouper une table de client et d'employé, le client n'aura jamais de poste, alors meme si c similaire, c différent
 
autre avis?

POur ma part je trouve que ton modèle est plus propre, plus cohérent et plus extensible en cas de reutilisabilité.
Maintenant si ton application est légère et est vouée à une utilisation standalone, le modèle de ton ami est parfaitement applicable.
 
Si vous voulez faire quelque chose qui vous satisfasse tous les deux vous pouvez faire un héritage en étendant le menu dans une table fils sous menu qui comprendrait uniquement les nouveaux champs du sous menu uniquement.
En relationnel cela peut se concrétiser par une table  
Menu (ID, Title, Position, Visible ) //eventuellement typeMenu
Et son fils sous menu (ID, Action, #ID)
 
 

jaime bien ta proposition
 
Menu: ID, Title, Position, Visible
 
Élément de menu: ID, Action, MenuID
 
d'un coté ca réutilise les champs répétitif que mon ami n'aimait pas, mais ca nous permet d'avoir un systeme de table beaucoup plus clair

jviens de regarder ca et cette méthode va pas très bien pour créer des menus
 
ex: jai 3 menus dans chacun a 2 éléments
 
Table menu
1 Menu1 1 True
2 Menu2 2 True
3 Menu3 3 True
4 SubMenu1 1 True
5 SubMenu2 2 True
6 SubMenu1 1 True
7 SubMenu2 2 True
8 SubMenu1 1 True
9 SubMenu2 2 True
 
Table SousMenu
1 Lien1 4
2 Lien2 5
3 Lien1 6
4 Lien2 7
5 Lien1 8
6 Lien2 9
 
Bon en réalité, mon Menu 4 devrait se trouver à etre un sous-menu du menu 1, en position 1. Mais la comment savoir de cette méthode qu'il doit être un sous-élément de 1? Il sait qu'il sera le premier Submenu d'un des menus, mais ne sait pas lequel.

Je pense que tu l'utilise mal.
Logiquement, l'ID de SousMenu doit etre le meme que celui du menu puisqu'il s'agit du meme element et la cle etrangere du ss menu menuID doit indiquer l'ID du menu auquel il appartient. Ca donnerait :
 
Table menu  
1 Menu1 1 True  
2 Menu2 2 True  
3 Menu3 3 True  
4 SubMenu1 1 True  
5 SubMenu2 2 True  
6 SubMenu1 1 True  
7 SubMenu2 2 True  
8 SubMenu1 1 True  
9 SubMenu2 2 True  
 
Table SousMenu  
4 Lien1 1  
5 Lien2 1  
6 Lien1 2  
7 Lien2 2  
8 Lien1 3  
9 Lien2 3
 
Tu obtiendrais tes ss menu avec :
select *  from menu, ssmenu where menu.id = ssmenu.id and ssmenu.ssid=1
(avec un group by adapté tu obtiens tout d'un coup)
 
Voila comment je modelise l'heritage mais vos methodes sont valable et il faut simplement utiliser la methode qui vous convient le mieux.

Le système de ton amis a un gros avantage :
- Récusrivité => Possibilité d'avoir un nombre infini de menus, et sur une même échèle, d'avoir des entrées de menu finales et des noeux pointants sur des sous-menus.
 
Le gros avantage, c'est que outre être plus propre niveau conception, c'est bien plus souple pour faire des menus plus complèxes.
 
MAIS ce système a un énorme inconvénient ! Très peux de SGBD sont capable de faire des requêtes récursives. A pas se fait, les informations seront difficiles (et donc lentes) à retrouver et mettre à jour.
 
Le meilleur moyen pour s'en sortir quand on n'a pas un SGBD capable de faire de la récursivité, c'est de faire des procédures stockées. Mais à nouveau, tous les SGBD (je pense notamment à MySQL version actuelles) ne supportent pas.
 
Donc ce système est très bon pour une base sous Oracle (supporte les requêtes récusrives avec les mots clés CONNECT BY et PRIOR)
Déconseillé mais utilisable avec SQL Server, Access (sisi), PostGRE, DB2, etc.
Inexploitable ou presque avec MySQL.
 
Le second système consite à créer une table menu avec cette structure (bien plus limité, mais très simplement utilisable)
 
MENU
niveau1
niveau2
niveau3
libelle
action
...
 
Et dedans :
 

 
C'est pas très propre, mais ça permet de récupérer assez simplement les infos. Deplus, ça accepte sur un même niveau des fins de menus et des noeuds. Par contre le nueau maximum des menus est codé en dur (ici 3)