Gegevens opdelen in tabellen sneller?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Mark Hogeveen

Mark Hogeveen

21/12/2022 21:09:10
Quote Anchor link
Stel dat ik bijvoorbeeld de volgende MySQL tabellen heb:

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
 
PHP hulp

PHP hulp

21/04/2024 10:21:39
 
Ward van der Put
Moderator

Ward van der Put

22/12/2022 06:43:14
Quote Anchor link
Als product_attributes de algemene attributen van producten bevat, dan zou ik store_attributes uitsluitend gebruiken voor de attributen van stores en een tabel product_store_attributes of store_product_attributes toevoegen voor de eigenschappen van producten die per store variëren.

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.
 
Ad Fundum

Ad Fundum

22/12/2022 20:48:20
Quote Anchor link
Waarom heb jij dan gekozen voor een SQL database? En niet voor NoSQL of Redis?

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
 



Overzicht Reageren

 
 

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.