Beste structuur voor table

Dusss ...

tabel category:
- id
- parent_id //null = hoofdcategorie
- name
- enz

tabel product:
- id
- category_id
- enz

Is er altijd maar één niveau in de categorieën, of kunnen dat er meer zijn (categorie -> sub-categorie -> sub-sub-categorie, enz)?

Om hoeveel producten gaat het grofweg?

@Rob Doemaarwat. Bedankt voor je reactie.

In de category tafel zijn twee niveaus.

 INSERT INTO `categories` (`id`, `parent_id`, `name`, `status`) VALUES
(1, NULL, 'Category 1', 1),
(2, NULL, 'Category 2', 1),
(3, 1, 'Sub 1 1', 1),
(4, 1, 'Sub 1 2', 1),
(5, 2, 'sub 2 1', 1),
(6, 2, 'sub 2 2', 1);

Het gaat om circa 400 producten

Alvast bedankt

Nou, bij 400 producten gaat dit prima (ik neem aan dat je een index op je product.category_id kolom hebt). Gewoon een join en klaar is Donald.

Pas vanaf een 1000000 producten ofzo zal zoeken op een hoofdniveau (dus meerdere sub-niveaus) merkbaar traag worden omdat je dan niet op een enkele sub-categorie zoekt (= bam op de category_id index in 1x resultaat), maar op meerdere categorieën (= meerdere category-id's = een "range condition" = als het tegen zit de hele tabel door akkeren). In dat geval zou je de hoofdcategorie dus evt. ook in de product tabel op kunnen nemen (zelf of via een trigger op de category_id bepalen). Maar voorlopig zou ik daar niet aan beginnen (alleen maar gedoe).

@Rob Doemaarwat. Hartstikke bedankt Rob

Dit zal vast op dovemansoren vallen but here goes:

Op *dit* moment vallen misschien alle producten in twee niveau's, maar wat als dit op den duur verandert? Heb je dan een structuur die hier in kan voorzien? En als daar geen sprake van is, hoe ingrijpend is dan een aanpassing?

Dan is daar het gedrag van je data: hoe verandert/groeit deze over tijd?

En dan is daar nog de code die inhaakt op deze datastructuur. Als je dingen anders wilt representeren/ordenen/filteren/whatever, wat moet hier dan in code aan huisgehouden worden? Moet de hele site/applicatie dan om?

[color=#009900]Mogelijk is een flexibele database-structuur waarbij je in code een fractie van deze flexibiliteit gebruikt wellicht nog het beste omdat je op deze manier bij groei niet door deze structuur wordt belemmerd. De database vormt vaak nog steeds het fundament van een applicatie. Is het fundament niet goed, dan ondervindt de applicatie hier hinder van.[/color]

Dit alles tezamen culmineert in een (of meer) ontwerpbeslissing(en) waarin wordt onderbouwd waarom je tot deze oplossing gekomen bent. Hiermee neem je de verantwoordelijkheid voor de aanpak. Dit is een van de verantwoordelijkheden van een applicatieprogrammeur.

Het is jouw taak om dit soort groei/verandering te overzien, of hier in ieder geval een inschatting van te maken en deze te toetsen bij mensen uit de betrokken vakgebieden.

Omdat wij niets weten over het gedrag van de data en de code die hier op inhaakt (plus andere spelende belangen zoals tijd, geld en prioriteit) is het niet mogelijk om op voorhand "de oplossing" te geven. Je zult dit zelf moeten inschatten en dan op grond hiervan een besluit nemen. Dit is een stukje eigen verantwoordelijkheid.

Met deze oplossing kun je ook eenvoudig naar meerdere niveaus groeien (3 en meer - oneindig).

Tegen de tijd dat het echt heel groot wordt zou het best kunnen dan je dingen "anders" wilt doen: sub-categorieën die in meerdere hoofd categorieën vallen; een tweede structuur die je producten op een heel andere manier doorkruist; enz.

Zoals Thomas zelf al aangeeft is het moeilijk om daar nu al op vooruit te lopen. In mijn ervaring is het ook niet *onmogelijk* om in de toekomst nog aanpassingen in je structuur te maken. De migratie is vaak nog vrij eenvoudig omdat je met een paar update queries de boel gewoon "om kunt hangen" (en vrij snel - zonder downtime van een heel weekend ofzo). Tegen de tijd dat je een miljoen producten in je database hebt zitten heb je waarschijnlijk al vele andere problemen moet tackelen die je nu totaal nog niet aan ziet komen. Een beetje schuiven met de categorie indeling is dan een "eitje".

Maar het is makkelijker om in de codelaag een "categorie cap" in te bouwen (max 1 of 2 niveau's diep) dan de structuur van de database om te gooien (en alles wat hier aanhangt).

Als het een kleine set is die toch niet veel verandert maakt het allemaal niet zoveel uit.

Graag wil ik bij deze topic nog het volgende vragen.
Ik wil per artikel eigenschappen toevoegen. Rekening houdend met normalisatie.
De structuur voor de categorieën gaat als volgt.
Tabel Artikelen_Indexatie

ArtikelId MerkId Categorie Subcategorie0 Subcategorie1 Subcategorie2

Vervolgens wil ik voor elk artikel eigenschappen kunnen toevoegen.
De artikelen verschillen veel. Van Speakers naar motoren enz.
Ik heb bv een tabel Eigenschappen_kleur , Eigenschappen_ipwaarde , Eigenschappen_vorm ,enz

Op deze manier kan ik nog steeds uitbreiden/aanpassen.

Om vervolgens deze eigenschappen op een artikel toe te passen... zit ik vast daar je geen lege velden wil hebben.

Zoiets als
Tabel Artikel_AlleEigenschappen

ArtikelId Eigenschap_kleur Eigenschap_vorm Eigenschap _ipwaarde Eigenschap_mperminuut

Als dan een artikel bv geen eigenschap mperminuut heeft heb ik een leeg veld.

Hoe los ik dit het beste op?

Alvast bedankt.

Zou je hiervoor een nieuw topic willen aanmaken? Dan blijven de discussies gescheiden.
Je kan uiteraard in je eigen topic linken naar dit topic.

Dit topic sluit ik om deze redenen. Als David behoefte aan heeft kan hij dit topic laten heropenen door een PM aan het moderatie-meldpunt te sturen.