[SGBD] Aide pour choisir entre 2 systemes de table

Aide pour choisir entre 2 systemes de table [SGBD] - SQL/NoSQL - Programmation

Marsh Posté le 08-06-2003 à 06:03:52    

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)


---------------
http://www.boincstats.com/signature/user_664861.gif
Reply

Marsh Posté le 08-06-2003 à 06:03:52   

Reply

Marsh Posté le 08-06-2003 à 11:00:33    

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)


---------------
from here and there -- \o__________________________________ -- la révolution de la terre, en silence
Reply

Marsh Posté le 08-06-2003 à 15:44:43    

simogeo a écrit :

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?


---------------
http://www.boincstats.com/signature/user_664861.gif
Reply

Marsh Posté le 08-06-2003 à 16:20:41    

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)
 
 


Message édité par Rob Roy le 08-06-2003 à 16:27:45
Reply

Marsh Posté le 08-06-2003 à 18:00:55    

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


---------------
http://www.boincstats.com/signature/user_664861.gif
Reply

Marsh Posté le 08-06-2003 à 18:17:46    

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.


---------------
http://www.boincstats.com/signature/user_664861.gif
Reply

Marsh Posté le 09-06-2003 à 04:04:55    

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.

Reply

Marsh Posté le 09-06-2003 à 21:17:56    

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 :
 

Code :
  1. 1   NULL   NULL   Acceuil            /home.php
  2. 2   NULL   NULL   Catalogue          NULL
  3. 3   NULL   NULL   Personnalisation   NULL
  4. 2   1      NULL   Pour les mères     NULL
  5. 2   2      NULL   Pour les pères     NULL
  6. 2   1      1      Fleurs             /cat/fleurs.php
  7. 2   1      2      Habits             /cat/habits.php
  8. 2   2      1      Voitures           /cat/voitures.php
  9. 2   2      2      Foot               /cat.foot.php
  10. ...


 
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)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed