[MYSQL] Ontwerp database en uitlezen van data

[Verwijderd]

Ik ben ter oefening een simpele webshop aan het opzetten. Producten kunnen geüpload worden met behulp van een CSV-bestand. Deze worden vervolgens door een simpel script weergegeven en als laatste kunnen de producten in een bestellijst komen te staan.

Ik worstel echter met de wijze waarop ik de producten en bijbehorende specificaties op sla in de database en deze vervolgens met behulp van een query ophaal.

Wat ik zelf had bedacht:

Optie 1
Prop alle verschillende producten in een tabel en het ophalen wordt een eitje (met behulp een uniek ID).

Problemen:
- Zo hoort het niet. De gegevens moeten worden genormaliseerd (toch?)
- Langzaam
- Producten kunnen niet geordend worden op specifieke eigenschappen

Optie 2
Maak voor elk product een aparte tabel zodat elke eigenschap netjes in zijn eigen kolom kan staan. Dit is netter en bovendien kunnen producten geordend worden op eigenschappen.

Problemen:
- De verschillende producten hebben niet ieder een uniek ID, dus wanneer de producten samenkomen in het bestelformulier is niet duidelijk welk product het is, laat staan dat duidelijk is uit welke tabel de gegevens gehaald moeten worden.

Optie 2.1
Ieder product moet herkenbaar en opvraagbaar zijn met behulp van een uniek ID. Dus er komt een aparte tabel die deze ID's opslaat en tevens in welke tabel dit product gevonden kan worden. Zo moet het lukken.

Problemen:
- Lijkt mij omslachtig, maar ik heb geen idee hoe ik het anders zou moeten doen
- Problematisch in verband met het uploaden van de CSV-bestanden (ieder product heeft zijn eigen CSV-bestand)

Wat ik me nu afvraag is: wat is de gangbare manier om dit te doen? Hebben jullie ervaring met een soortgelijke opbouw van een database van een webshop. Welke technieken kunnen me helpen om het probleem op te lossen? Joins? Of pak ik het helemaal verkeerd aan? Ik hoop dat het enigszins duidelijk is.

[mathijs92]

Voor elk product een aparte tabel is naar mijn idee geen goed idee, ik zou gaan voor een vorm zoals optie 1, de opties kun je misschien in een andere tabel opslaan (met de kolommen: id,product_id, eigenschap, waarde). Maar dat ligt nogal aan het aantal eigenschappen enz.

En 1 grote tabel hoeft zeker niet langzaam te zijn, zeker niet met goede indexen

[ Voor 14% gewijzigd door mathijs92 op 09-10-2009 18:17 ]

[Verwijderd]

Een tabel met Producten en eentje met eigenschappen? Dus voor elk product maak je 1 record aan, en vervolgens stop je alle eigenschapen met een verwijzing naar het product in een andere tabel. Eventueel kun je nog een 3e tabel gebruiken, om de naam van de eigenschappen op te slaan, en vervolgens in een koppel tabel het product, de eigenschap en de waarde van de eigenschap opgeven.
Dus in dat geval:

Products
- id
- naam

Properties
- id
- naam

Products_Properties
- productId
- propertyId
- value

[Danot]

Ik raad je aan om eens te kijken naar de standaard voorbeelden van databases met producten, productgroepen, orders, klanten, orderregels etc.
Dan zul je waarschijnlijk een beter idee krijgen van de entiteiten in jouw casus. Denk bij het modelleren van je database niet aan de query's waarmee je producten wilt tonen, maar denk aan hoe je de data het beste kunt opslaan. Dus voorkom redundantie en behoud referentiële integriteit.

[Verwijderd]

@ Mathijs92:

Klopt mathijs, maar in dit geval is het inderdaad zo dat er per product zo'n 9 á 10 eigenschappen zijn die ieder zijn eigen kolom moet hebben. En is het zo dat er een product bij komt dan moet je de hele tabel aanpassen in plaats van simpelweg een nieuwe tabel erbij.

@ Kage

Dit ziet er goed uit Kage, hoewel ik nog niet helemaal snap hoe het geheel in elkaar zit. Ik denk dat het probleem hierbij is dat elke productcategorie heel verschillende eigenschappen heeft.

@ Danot

Goede tip, maar waar precies kan ik dat soort dingen vinden (of met wat voor zoektermen)? Of is google opnieuw onze grote vriend?

[ik222]

Een product met zijn eigenschappen zou ik gewoon bij elkaar laten, met als primary key het ProductID en verder een kolom voor elke eigenschap. Dat hoort gewoon bij de entiteit product en ik snap niet waarom je dat zou willen splitsen?

Dat is ook het handigste aangezien je in orderegels etc. dan weer gewoon kunt verwijzen naar dat ProductID aan de hand waarvan dan weer altijd alle informatie over dat product is terug te halen.

[ Voor 4% gewijzigd door ik222 op 09-10-2009 18:35 ]

[JordyOnrust]

Je hebt te maken met een meer op meer relatie. Meerdere artikelen kunnen meerdere eigenschappen hebben en anders om, meerdere eigenschappen kunnen bij meerdere artikelen horen. Dus:

Tabel: Producten:
ID
en alle Unieke waarden van het product

Tabel: Eigenschappen
ID
Alle voorkomende eigenschappen.

Tabel: Eigenschappen_Producten
productID
eigenschap ID
Dit is de koppel tabel
Deze tabel koppelt de eigenschappen aan de artikelen.

Zo kun je dit ook met andere zaken in een db doen.
Bijvoorbeeld users <-> rechten.

[Verwijderd]

@ Bright010957

Oke lijkt erg op de oplossing van Kage alleen wat uitgebreider uitgelegd, maar ik zie het nog niet voor me. Normaliseren en Joins is nou niet iets waar ik nog al te veel ervaring mee heb. Niets wat een aantal tutorials niet kunnen verhelpen, maar in relatie tot de producten die ik op het oog heb is het me toch niet duidelijk.

Even wat uitgeschreven:

Tabel Producten:
Hier komen alle producten. Elk product heeft bij mij zo'n 9 a 10 unieke waarden (allemaal technische specificaties verschillend voor elke product). Is dit dan niet gewoon hetzelfde als alles in één tabel stoppen?


Tabel Eigenschapppen:
Alle voorkomende eigenschappen onafhankelijk van product, dus dat komt er als volgt uit te zien:

id | Eigenschappen
1 | Eigenschap 1
2 | Eigenschap 2
3 | Eigenschap 3
4 | Eigenschap 4
5 | Eigenschap 5

etc.

Koppeltabel:
Hier krijgt ieder product zijn eigenschappen toegewezen, dus:

Product_id | Eigenschappen_id
1 | Eigenschap 1 | Eigenschap 2 | etc.
2 | Eigenschap 1 | Eigenschap 2 | etc.
3 | Eigenschap 1 | Eigenschap 2 | etc.
4 | Eigenschap 1 | Eigenschap 2 | etc.

etc.

Volgens mij klopt er niet zoveel van 't bovenstaande . Waar ga ik de fout in?

[JordyOnrust]

De koppel tabel klopt niet.

Product_id Eigenschap_id:
1 1
1 3
2 4
2 5
3 1
3 4
3 5

Etc...

Dus elke eigenschap id aan een product id.

[BCC]

Op het moment dat je dit gaat doen ben je wel bezig een database-anti pattern te bouwen. Omdat je later de producten ook weer wil geven / wil bestellen zou ik toch echt kijken of je niet 1 generieke tabel kan maken waar alles in past.

Dit soort constructies gaan je ook erg veel problemen geven als je applicatie wat groter wordt. Zie bijvoorbeeld dit uit de hand gelopen probleem: [MySQL] hoe te optimaliseren?

[ Voor 13% gewijzigd door BCC op 09-10-2009 19:34 ]

[RobIII]

Verwijderd schreef op vrijdag 09 oktober 2009 @ 18:15:
Een tabel met Producten en eentje met eigenschappen? Dus voor elk product maak je 1 record aan, en vervolgens stop je alle eigenschapen met een verwijzing naar het product in een andere tabel. Eventueel kun je nog een 3e tabel gebruiken, om de naam van de eigenschappen op te slaan, en vervolgens in een koppel tabel het product, de eigenschap en de waarde van de eigenschap opgeven.

Ik quote mezelf even uit een ander topic...

RobIII schreef op donderdag 08 oktober 2009 @ 18:23:
Ah, het bekende "database-in-een-database" probleem
Misschien moet je eens kijken naar HBase, BigTable, HyperTable en consorten. Misschien dat je daar wat aan hebt. De weg die je nu ingeslagen bent is, mark my words, doodlopend. Bedenk eens welk type je "value" gaat geven. Dit wordt geheid een string (want anders past niet "alles" er in). En bedenk dan eens hoe je selecties gaat maken als "alles met meer dan 2 of meer badkamers" of "alles met reisdatum na 15-12-2009"

RobIII schreef op vrijdag 09 oktober 2009 @ 19:14:
[...]

Dit heb ik echt al honderden keren zien gebeuren en ze zijn allemaal, stuk voor stuk, geen enkele uitzondering daargelaten op hun bek gegaan en al brandend de diepte in gezonken. Ja, met wat creatief query-en en wat creatief programmeren kom je een héél eind. Totdat de performance je de nek om draait (alles is "string"), of de wat "ingewikkeldere" queries (waarbij ingewikkeld in deze context nog peanuts is want een 2 voorwaardes in een WHERE clause wordt al lastig) draaien je de nek om. En anders komen de constraints die je normaliter zou hebben je in je hol schoppen omdat je ze nu niet meer kunt gebruiken, en op geen enkele manier wat dan ook nog kunt afdwingen. En als je dat allemaal weet te voorkomen komt op een goede dag je DB zélf je een rotschop in je muil verkopen, out of the blue, gewoon... om je te jennen Harig is nog optimistisch zeg maar

[Verwijderd]

OK . Dit is iets wat je dus niet wilt. Is het dan gewoon het beste om alles in 1 tabel te doen zoals BCC zegt? Ongeacht dat dit per productcategorie zo'n 9 à 10 kolommen gaat kosten met het gevolg dat de tabel zeg 90 tot 100 kolommen lang wordt?

Dat moet een DBMS toch wel aan kunnen ook al zijn het 500 kolommen?

Edit:

Ah kijk, 't is mogelijk.
Link mysql reference manual

[ Voor 30% gewijzigd door Verwijderd op 09-10-2009 21:01 ]

[JordyOnrust]

Is zo'n eigenschap gewoon één woord, of zeg je er bijvoorbeeld meer over.
Naam, omschrijving etc. Dan zou ik het wel in een aparte tabel zetten.

Je zelf nooit herhalen, zowel niet in programmeren, als in bijvoorbeeld een database.
Als je nou eens een voorbeeld geeft met wat informatie. 2 of 3 producten met de bij behordende eigenschappen.
Misschien wordt het dan al wat duidelijker.
Maar alles in één table stoppen is een verkeerde manier van het opzetten van een db schema.
Voorkom en alle tijden meer op meer relaties, maar gebruik koppel tabellen.

Misschien heb je hier wat aan.
Link naar uitleg database.
Als er zaken niet in kloppen, geen idee, heb het niet honderd procent doorgelezen, even vluchtig, maar lijkt wel redelijk goed. Misschien heb je er wat aan.

[Verwijderd]

Er zijn tot nu toe 2 verschillende productcategorieën, maar in de toekomst zullen dit er meer worden. De eerste twee producten betreffen het banden en velgen.

Hier wat gegevens:

Banden:

Merk	Naam	Type	Bandbreedte	Verhouding	Velgmaat	LI	SI	Prijs	Aanbieding
AUTOGUARD	S900XL	Zomerbanden	205	40	17	84	W	49.147	1
AUTOGUARD	S900XL	Zomerbanden	215	45	17	91	W	57.03075
BFGOODRICH	ATTAKO	Zomerbanden	215	75	15	100	S	119.8925

Velgen:

Merk	Naam	Inch	Prijs	Bandbreedte	Verhouding	Velgmaat	Steek	Aanbieding
ELITE	Hyper Black	16	780	205	55	16		1
ELITE	Shark Hyper Black	17	885	225	45	17
RVS	Falcon Antraciet	16	820	205	55	16

@ Bright010957

Bedankt voor de link. Ik heb nu ook meer van soortgelijke artikelen gelezen en begin het behoorlijk te snappen, maar ik kan de stap van de gegeven voorbeelden naar mijn producten gewoon niet maken. Heel frustrerend!

[ Voor 7% gewijzigd door Verwijderd op 10-10-2009 14:17 ]

[djluc]

Brr, die maat 1-3 ziet er vies uit.

[Verwijderd]

Ziet er vies uit, maar bij autobanden en velgen zijn er inderdaad drie maten waar rekening mee gehouden moet worden.

[Verwijderd]

djluc schreef op zaterdag 10 oktober 2009 @ 14:00:
Brr, die maat 1-3 ziet er vies uit.

Dat zijn bandmaten Maar misschien is het inderdaad beter ze gewoon:
* Bandbreedte
* Verhouding
* Velgmaat
te noemen. Dat voorkomt verwarring (en opmerkingen over normaliseren, wat de namen maat1,.. zeker uit zal lokken).

[Verwijderd]

Dat is inderdaad een stuk duidelijker. Ik verander het even (Kijk boven).

[JordyOnrust]

Ik zou gewoon voor elk soort artiel een eigen tabel maken.
De verschillen zijn dusdanig dat het denk ik niet relevant is de artikelen samen in een tabel te zetten.

Alleen wanneer je echt zaken tegen komt die echt overeen komen voor alle artikelen zou je een apparte tabel kunnen maken voor artikel.
Maar in de tabel artikel kom je dan alleen zaken tegen als artikel nummer, prijs etc. Maar je kunt ook gewoon losse tabelen gebruiken.

Alleen dan moet je van te voren wel bedenken welke zaken je wilt gaan gebruiken.
Dan is het opzich lastig om later nog weer een nieuwe artikel groep te te voegen met bijvoorbeeld een CMS. De denk goed na over wat je precies wilt bereiken.