Gegevens opdelen in tabellen sneller?
products
Tabel met producten.
id, created_at, updated_at, name, description, barcode
product_attributes
id, product_id, attribute_name, attribute_value
stores
id, name, description, address
store_attributes
id, product_id, attribute_name, attribute_value
Merk op dat de tabellen product_attributes en store_attributes eigenlijk hetzelfde zijn.
De applicatie heeft de mogelijkheid om aan producten en aan stores attributen te koppelen in de vorm van een simpele key-value vorm.
Bij het maken van dit simpele systeem, had ik twee mogelijkheden voor de attributen tabellen:
1. Twee tabellen, dus product_attributes en store_attributes zoals ik het nu heb gedaan.
2. Eén tabel, bijvoorbeeld attributes waarin ik de key-value pairs voor zowel producten als stores in opsla.
Zie het even helemaal los van eventuele toekomstige aanpassingen of uitbreidingen.
Bij het laden van een product, moeten zijn attributen ook worden opgehaald. Bij het laden van een store moet precies hetzelfde gebeuren.
Ik vraag me af of het voordelen heeft qua snelheid als de attributen voor producten en voor stores in een aparte tabel staan. Mijn gedachte is: als ik alle attributen in een algemene attributes tabel opsla, heb ik één grote tabel. Als ik aparte tabellen maak (product_attributes en store_attributes), en MySQL de attributen voor een product bij elkaar moet zoeken, moet hij kijken in een tabel waar alleen product attributen in staan. En die aparte tabel voor product attributen is altijd kleiner dan één algemene tabel waar ik alle attributen voor verschillende dingen in zou opslaan (producten én store attributen door elkaar).
Is mijn gekozen oplossing sneller bij het ophalen van gegevens, omdat ik MySQL in een specifieke (kleinere / niet "gemengde") tabel laat zoeken omdat ik de data doe scheiden over tabellen, of werkt het niet zo?
Gewijzigd op 21/12/2022 21:11:12 door Mark Hogeveen
Waarschijnlijk moet je dan ook nog wat verplaatsen. Om duplicate content tegen te gaan, wil je voor SEO-doeleinden bijvoorbeeld de description van een product per store kunnen variëren.
Over performance valt weinig concreets te zeggen. Ik denk dat je je vooral bewust moet zijn van de trade-off van een key-value store. Aanvankelijk is de tabel klein en kun je met full index coverage alle keys plus values in het geheugen houden: dat is extreem snel. Naarmate de database groeit, gaat hetzelfde ontwerp echter tegen je werken omdat je alles in één grote tabel bewaart.
De oplossing die je had was al de beste. Ook al zijn gegevens gelijkvormig (zelfde tabelindeling) wil dat nog niet zeggen dat het ook dezelfde soort gegevens zijn (winkel vs product).
Het zou namelijk makkelijk kunnen zijn dat de behoefte later nog een keer verandert voor alleen winkels. Zeg dat je beschrijving aan een bepaald format moet voldoen, dan kan je een CHECK constraint toevoegen aan de tabel van alleen de winkels.
Om tegemoet te komen aan de behoefte om gelijkvormigheid, hebben databases een mogelijkheid voor table inheritance.
Gewijzigd op 24/12/2022 12:18:35 door Ad Fundum