[MySQL]Database ontwerp

Pagina: 1
Acties:

  • Liqued
  • Registratie: Februari 2001
  • Laatst online: 09-01 18:51
Hoe zou jij het volgende ontwerpen?

Ik heb gewoon een standaard tabbel met wat gegevens er in. Nu moet er aan deze tabbel meer gegeven gekoppeld worden die hiërarchisch geordend moet zijn en "oneindig" veel subniveau's moet hebben.

Voorbeeld:
code:
1
2
3
4
5
6
7
8
9
10
11
================
| Basis tabbel |
================
  |
  |-|sub gegevens van de basis tabbel|
  |            |
  |       |sub gegevens van de basis tabbel|
  |                    |
  |                |sub gegevens van sub gegevens|
  |
  |-|sub gegeven van de basis tabbel|

  • twiekert
  • Registratie: Februari 2001
  • Laatst online: 10:45
table node:
kolommen: id, omschrijving, parentid.

of:

table node:
kolommen: id, omschrijving

table node_relation:
kolommen: node_id, parent_id

/edit:

er zijn trouwens veel nuttige topics in de search te vinden, ik heb namelijk zelf ook net een tree gebouwd:

http://search.gathering.t...-XF53-XF6-XF7-XF8-XF9---A

[ Voor 68% gewijzigd door twiekert op 15-07-2003 14:00 ]


Verwijderd

Bijvoorbeeld een menu:
code:
1
2
3
optie1
|- optie1.1
   |- optie1.2


Is heel simpel te realiseren (qua db model dan):

menu( id, naam, parentid );
parent id verwijst dan naar id en mag null zijn.

Rest spreekt voor zich mag ik aan nemen...

/me is traag vandaag

[ Voor 5% gewijzigd door Verwijderd op 15-07-2003 14:01 ]


  • DukeMan
  • Registratie: Mei 2000
  • Niet online
twiekert schreef op 15 July 2003 @ 13:59:
table node:
kolommen: id, omschrijving, parentid.
Idd, ik zou het ook zo doen...
Parentid = "" bij de top items of bevat de id van het bovenliggende item.

[ Voor 3% gewijzigd door DukeMan op 15-07-2003 14:02 . Reden: Te laat, zie NextGeneration ]


  • Liqued
  • Registratie: Februari 2001
  • Laatst online: 09-01 18:51
Ok, met die parentid snap ik wel, maar het probleem zit hem in het feit dat de basis tabbel anders is dan de sub gegevens.. en je dus eigelijk 2 parentids moet hebben (1 voor de basis tabbel en 1 voor als iets een sub van een sub is).

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Liqued schreef op 15 juli 2003 @ 14:06:
Ok, met die parentid snap ik wel, maar het probleem zit hem in het feit dat de basis tabbel anders is dan de sub gegevens.. en je dus eigelijk 2 parentids moet hebben (1 voor de basis tabbel en 1 voor als iets een sub van een sub is).
Hoe groot is dat verschil dan?
Te groot om de tabellen samen te voegen?

  • Liqued
  • Registratie: Februari 2001
  • Laatst online: 09-01 18:51
ACM schreef op 15 July 2003 @ 14:08:
[...]

Hoe groot is dat verschil dan?
Te groot om de tabellen samen te voegen?
Het zijn gewoon totaal verschillende gegevens. De structuren van de tabbelen zijn geheel anders. Bovendien verander ik de basis tabbel liever niet aangezien die al enige tijd bestaat en veel gegevens in zitten.

  • samo
  • Registratie: Juni 2003
  • Laatst online: 20:15

samo

yo/wassup

Ik ben hier gisteren ook mee gaan spelen voor mn eigen cms achtge website (in aanbouw).
Ik had namelijk een hoofdmenu, submenu en een pagina.
Nu heb ik ieder menu een andere ID gegeven, en die ID heb ik uit 2 subID's opgebouwd
dus letterlijk:
ID1_ID2 waardoor je makkelijk kan zien of iets een sub van welk ID is.
dan heeft de index pagina dus id: 01_xA
vervolgens worden alle berichten voor 01_xA geladen in dit veld...
ik gebruik hier verder de x als "leeg veld" omdat de letters allemaal hoofletters zijn...

dus jij zou ook kunnen doen:
id:
01-01-01-02-05
ofzo....
waar je submenu's kan blijven toevoegen

edit:
whoops ik had 2 reply's niet gezien, kweet dus niet of dit een toevoeging is...

[ Voor 10% gewijzigd door samo op 15-07-2003 14:14 . Reden: 2 new posts ]

Bekend van cmns.nl | ArneCoomans.nl | Het kindertehuis van mijn pa in Ghana


Verwijderd

de oplossing van twiekert is dan nog steeds goed, je kan gewoon een extra tabel maken die tussen twee tabellen links maakt

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Magoed, zoveel maakt het niet uit toch?

Dan maak je een tweetal relaties: basis_tabel_id, sub_tabel_id voor de eerste laag, sub_tabel_id, sub_tabel_parent voor de tweede laag?

Een andere variant is om in je sub_tabel een parent_id op te nemen, die verwijst naar de basis_tabel en die null maken als er geen parent in de basis-tabel zit.

De oplossing van tweikert geeft trouwens een n:m relatie, als dat niet nodig is kan de sub_tabel evt ook een parent_id naar zichzelf bevatten en daarmee een 1:n relatie aanbieden.

[ Voor 22% gewijzigd door ACM op 15-07-2003 14:16 ]


Verwijderd

Het maken van een parent-child-constructie op database-niveau is inderdaad makkelijk. Het word echter een stuk lastiger wanneer je op applicatie-niveau oneindig diepe bomen wilt maken. Wanneer je dit wilt bereiken zul je gebruik moeten maken van recursieve functies..
Pagina: 1