Beste structuur voor table
Gewijzigd op 21/10/2018 14:49:18 door Donald Boers
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?
In de category tafel zijn twee niveaus.
Code (php)
1
2
3
4
5
6
7
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);
(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
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).
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.
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".
Als het een kleine set is die toch niet veel verandert maakt het allemaal niet zoveel uit.
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.
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.