Beste structuur voor table

Overzicht

Sponsored by: Vacatures door Monsterboard

Donald Boers

Donald Boers

21/10/2018 14:38:56
Anchor link
Ik werk aan een site met een categorieen, een sub_categorieen en een producten. Momenteel heb ik het zo dat de categorie en de sub categorie in een tafel staan waarbij ik parent_id gebruik om deze met elkaar te linken. Verder heb ik een product tafel. Via de navigatie moet een bezoeker zowel zowel de gehele categorie als alleen een sub categorie kunnen aanroepen. Wat is de best tafel structuur hiervoor. En dan bedoel ik met name hoe ik de de product tafel met de categorie tafel link
Gewijzigd op 21/10/2018 14:49:18 door Donald Boers
 
PHP hulp

PHP hulp

03/12/2024 21:09:28
 
Rob Doemaarwat

Rob Doemaarwat

21/10/2018 14:49:22
Anchor link
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?
 
Donald Boers

Donald Boers

21/10/2018 15:02:02
Anchor link
@Rob Doemaarwat. Bedankt voor je reactie.

In de category tafel zijn twee niveaus.
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
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
 
Rob Doemaarwat

Rob Doemaarwat

21/10/2018 15:13:58
Anchor link
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).
 
Donald Boers

Donald Boers

21/10/2018 15:31:52
Anchor link
@Rob Doemaarwat. Hartstikke bedankt Rob
 
Thomas van den Heuvel

Thomas van den Heuvel

21/10/2018 15:54:05
Anchor link
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?

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.

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.
 
Rob Doemaarwat

Rob Doemaarwat

21/10/2018 19:47:17
Anchor link
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".
 
Thomas van den Heuvel

Thomas van den Heuvel

21/10/2018 22:11:31
Anchor link
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.
 
Bart Smulders

Bart Smulders

27/01/2019 11:57:36
Anchor link
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.
 
- Ariën  -
Beheerder

- Ariën -

27/01/2019 13:49:19
Anchor link
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.
Gewijzigd op 27/01/2019 13:55:23 door - Ariën -
 
 

Dit topic is gesloten.



Overzicht

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.