In het Database Doorlinken Subcategorie.
Wie kan mij helpen met het doorlinken van verschillende categorieen voor een linksite.
Er moet gekoppeld worden vanaf "Hoofdcategorieen" naar " Subcategorien" en dan door naar Subsubcategorieen.
dat is op zich geen probleem maar bij "subsubcategorieen" moeten de "subcategorieen" nog boven aan staan en de inhoud onderaan in het scherm.
Op de 3de pagina (bij subsubcategorieen) moeten de "subcategorieen" naar zichzelf verwijzen. en dit lukt niet. en als ik naar links.php verwijs komen de links boven en onderaan verdeeld terwijl dit in een aparte plek moet komen.
Is ook hier een manier voor?
Vriendelijke Groeten.
Je kunt de subcategorieën eerst echoën en daarna pas de inhoud van de subsubcategorieën echoën.
Als ik je laatste alinea goed begrijp, moeten de subcategorieën een link vormen die -wanneer er op geklikt wordt- naar de pagina bijbehorend aan die subcategorie gaat. Dat zou toch geen probleem moeten geven?
Geef anders even een voorbeeldje.
Code (php)
1
2
3
4
5
2
3
4
5
categories
=======
cat_id
cat_name
cat_parent
=======
cat_id
cat_name
cat_parent
Als er geen cat_parent is dan is het een hoofdcategorie.
Zie de handleiding van jouw database voor de details.
Edit: Een sub-sub-categorie is een categorie met een parent die ook weer een parent heeft. Niks bijzonders dus.
Gewijzigd op 01/01/1970 01:00:00 door Frank -
Djemo schreef op 17.03.2008 17:47:
@Jurgen: hoe wil je subcategorieën en subsubcategorieën dan onderscheiden?
Als een categorie een parent heeft dan is dit een subcategorie.
We hebben dus allemaal ID's
Hoofd Categorieen(HC) hebben geen parent en staan links in de html pagina
Sub categorieen(SC) hebben 1 parent en staan boven aan in midden van de html pagina.
Sub Sub Categorieen(SSC) Hebben 2 parents en staan ook op de zelfde plek als sub Categorieen alleen deze heeft onderaan in de midden van de html een links overzicht nodig.
Wat wij probeerden was b.v. HC ->(id=1) SC ->(id=2) SSC ->(id=2)
Want als je op de laatste SSC links klikt moet die op dezelfde pagina blijven.
Maar dit werkt niet.
SC moet niet alleen linken naar SSC maar ook naar de links die onderaan staan op de zelfde pagina bij SSC.
Is moeilijk uit te leggen maar ik hoop dat je em snapt
Vriendelijke groeten
stef schreef op 17.03.2008 18:03:
Dat is vreemd, dat klopt namelijk niet. Een sub-sub-categorie heeft 1 parent. Deze ene parent heeft echter ook weer een parent. Dat is wat anders dan een sub-sub-categorie met 2 parents, dat zou namelijk betekenen dat 1 sub-categorie in 2 categorieen valt. Wat overigens best zou kunnen.Sub Sub Categorieen(SSC) Hebben 2 parents
Eén boek kan namelijk zowel in de categorie PHP als SQL vallen die beiden weer in de categorie computers vallen.
Jurgen schreef op 17.03.2008 18:00:
Als een categorie een parent heeft dan is dit een subcategorie.
Djemo schreef op 17.03.2008 17:47:
@Jurgen: hoe wil je subcategorieën en subsubcategorieën dan onderscheiden?
Als een categorie een parent heeft dan is dit een subcategorie.
Dat begrijp ik. Maar jij vertelt net dat je met dat datamodel oneindig veel soorten categorieën kan opslaan. Daaronder versta ik ook subsubcategorieën. Als bij een subcategorie parent dus is ingevuld, is het een subcategorie, maar bij een subsubcategorie is deze ook ingevuld! Hoe wil je dat gaan onderscheiden?
Djemo schreef op 17.03.2008 18:23:
Dat begrijp ik. Maar jij vertelt net dat je met dat datamodel oneindig veel soorten categorieën kan opslaan. Daaronder versta ik ook subsubcategorieën. Als bij een subcategorie parent dus is ingevuld, is het een subcategorie, maar bij een subsubcategorie is deze ook ingevuld! Hoe wil je dat gaan onderscheiden?
Jurgen schreef op 17.03.2008 18:00:
Als een categorie een parent heeft dan is dit een subcategorie.
Djemo schreef op 17.03.2008 17:47:
@Jurgen: hoe wil je subcategorieën en subsubcategorieën dan onderscheiden?
Als een categorie een parent heeft dan is dit een subcategorie.
Dat begrijp ik. Maar jij vertelt net dat je met dat datamodel oneindig veel soorten categorieën kan opslaan. Daaronder versta ik ook subsubcategorieën. Als bij een subcategorie parent dus is ingevuld, is het een subcategorie, maar bij een subsubcategorie is deze ook ingevuld! Hoe wil je dat gaan onderscheiden?
Sub-sub bestaat niet.
De categorie weet alleen of hij een parent heeft (als cat_parent is ingevuld) de parent hoeft dit zelf niet te weten. etc, zo kunnen sub categorieen ook weer parents zijn van andere categorieen.
Als je hier een functie voor schrijft kun je heel mooi recursief een UL/LI menu maken doe ook nog eens klopt!
Gewijzigd op 01/01/1970 01:00:00 door Jurgen assaasas
Bij dit soort situaties ga je niet van boven (parent) naar beneden (child) werken, maar altijd van beneden naar boven werken. Je pakt dus een child en kijkt welke parent daar bij hoort. Bij deze parent ga je ook weer een parent zoeken. Van dit resultaat ga je vervolgens ook weer de parent opzoeken. Je gaat net zolang door totdat er geen parents meer zijn. Dat weet je pas hoeveel lagen jouw structuur heeft en of jouw oorspronkelijke input (de child waarmee je bent begonnen) een sub-sub-sub-sub-categorie of een sub-sub-sub-categorie is.
Dit is ook direct het nadeel van deze opzet, het kan erg complex worden.
Als jij zo een datamodel gaat opbouwen, gooi je alles door elkaar. Nergens staat wat een hoofdcategorie of een subcategorie is. En het klopt, die subcategorie kan weer een parent zijn van een (sub)subcategorie. Maar hoe wil je dat gaan onderscheiden als dat nergens staat aangegeven?
Een subcategorie zal er hetzelfde uitzien als een (sub)subcategorie.
Djemo schreef op 17.03.2008 18:29:
Dat ligt aan jouw presentatie, dat heeft niks met het datamodel te maken.Een subcategorie zal er hetzelfde uitzien als een (sub)subcategorie.
Quote:
Er zit nooit een volgorde in records, dat is hier dus niet anders.Als jij zo een datamodel gaat opbouwen, gooi je alles door elkaar.
Quote:
Klopt, deze betekenis ken je pas toe in je weergave. Een record heeft een parent (is dus een sub-) of geen parent (hoofd, maar wellich zonder childs)Nergens staat wat een hoofdcategorie of een subcategorie is.
Quote:
Dat is een kwestie van de data uitspitten en uitvogelen wat nu waar staat. Dat is ook het nadeel van deze opzet, dit kan erg ingewikkeld en dus tijdrovend worden. Het geeft je wel maximale flexibiliteit. Hardcoded tabellen (hoofd, sub en sub-sub) hebben als nadeel dat je niet een hoofdcategorie kunt weggooien zonder eerst zijn subcategorieen ergens anders onder te brengen of zelfs te verplaatsen naar de hoofdcategorieen. Dat brengt dus ook weer een hoop extra werk met zich mee.Maar hoe wil je dat gaan onderscheiden als dat nergens staat aangegeven?
1 tabel heeft mijn voorkeur, wanneer je dat 1x goed opzet heb je er vervolgens geen werk meer van. Mocht performance een probleem worden, ga je de resultaten wat langer cachen, dan lost dat probleem zich ook weer op.
Voorbeeldje:
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
ID | Cat_naam | Cat_parent
1 | Hoofd1 |
2 | Sub1 | 1
3 | Sub2 | 1
4 | Sub3 | 1
5 | Subsub1 | 2
6 | Hoofd2 |
7 | Sub4 | 6
8 | Subsub2 | 4
1 | Hoofd1 |
2 | Sub1 | 1
3 | Sub2 | 1
4 | Sub3 | 1
5 | Subsub1 | 2
6 | Hoofd2 |
7 | Sub4 | 6
8 | Subsub2 | 4
Djemo schreef op 17.03.2008 19:21:
Het zal er inderdaad wat rommelig uit gaan zien. Ben het even uit gaan schrijven, en kwam tot de conclusie dat het wel duidelijk blijft. Een subcategorie met het ID 2 kan nl. nooit een hoofdcategorie worden. Dus een subsubcategorie met als parent subcategorie 3, blijft daar ondergebracht. In de database zal het een rommeltje worden, maar bij een goede output zal alles duidelijk zijn.
Voorbeeldje:
Voorbeeldje:
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
ID | Cat_naam | Cat_parent
1 | Hoofd1 |
2 | Sub1 | 1
3 | Sub2 | 1
4 | Sub3 | 1
5 | Subsub1 | 2
6 | Hoofd2 |
7 | Sub4 | 6
8 | Subsub2 | 4
1 | Hoofd1 |
2 | Sub1 | 1
3 | Sub2 | 1
4 | Sub3 | 1
5 | Subsub1 | 2
6 | Hoofd2 |
7 | Sub4 | 6
8 | Subsub2 | 4
Je slaat hier en daar een plank mis. Wanneer je bij id 2 de parent op NULL zet, is het een hoofdcategorie geworden. Subsub1 worden dan automatisch een sub-categorie, zijn parent heeft namelijk geen parent meer. Dat is juist voordeel van deze structuur.
In de database wordt het geen rommeltje, alles is keurig genormaliseerd en logisch opgeslagen. Daar komt nog eens bij dat een database niet is gemaakt om de boel op te ruimen, je kunt op duizenden verschillende manieren de data opvragen, sorteren, gebruiken, presenteren, etc. etc. Dat heeft allemaal niks te maken met 'een rommeltje in de database'.
Het zal hier niet voorkomen, maar zet maar eens een paar miljoen records in de database, dat is voor het menselijk altijd een berg spagetti waar men geen overzicht meer heeft. Dat is ook niet nodig, daar heb je de DBMS voor.