Aparte tabel of Explode?

[Saeverix]

Ik moet een keuze maken, maar kom er zelf niet uit. Daarom heb ik iemand met een andere kijk nodig die misschien een geweldige oplossing ziet.

Ik ben een webshop aan het maken en het moet mogelijk zijn om per product verschillende maten met bijhorende prijzen in te kunnen voeren.

Bijvoorbeeld: Product 1 (10x15 2,50 euro) (20x30 6,00 euro) etc.

Voor alle producteigenschappen had ik al een universele opbouw gemaakt. Namelijk 3 tabellen. Eentje voor de naam van de eigenschap (bijvoorbeeld Categorie of Kleur). Een tabel voor de werkelijke waarde van de eigenschap (bijvoorbeeld "Categorie 1" of "Rood"). En uiteindelijk een koppeltabel om de waardes aan de producten te koppelen.

Op die manier kan ik later gemakkelijk een eigenschap toevoegen zonder de hele database overhoop te moeten halen.

Alleen voor het opgeven van de afmetingen met bijhorende prijzen gaat dit niet lukken. Tenzij ik zoals ik bedacht had de waarden als volgt invoer: "10x15 2,50 euro" wordt dan "10|15|2,50".

Bij het opvragen van de afmetingen en prijzen zal ik dan per regel een explode moeten uitvoeren. En dat is wat me niet helemaal lekker zit. Volgens mij komt dit de performance niet ten goede.

De andere optie die ik toen bedacht had was om een aparte tabel aan te maken waarin ik de afmetingen en de prijzen zet en vervolgens ook koppel aan het product. Alleen dan is zonder omdat ik dan alsnog iets doe wat ik met de "universele" tabellen had willen voorkomen.

Dit is echt zo'n geval waarbij je een mening van iemand anders nodig hebt omdat je het zelf niet meer ziet.

[Fish]

Saeverix schreef op zaterdag 02 juli 2011 @ 18:30:
Ik moet een keuze maken, maar kom er zelf niet uit. Daarom heb ik iemand met een andere kijk nodig die misschien een geweldige oplossing ziet.

Ik ben een webshop aan het maken en het moet mogelijk zijn om per product verschillende maten met bijhorende prijzen in te kunnen voeren.

Bijvoorbeeld: Product 1 (10x15 2,50 euro) (20x30 6,00 euro) etc.

Voor alle producteigenschappen had ik al een universele opbouw gemaakt. Namelijk 3 tabellen. Eentje voor de naam van de eigenschap (bijvoorbeeld Categorie of Kleur). Een tabel voor de werkelijke waarde van de eigenschap (bijvoorbeeld "Categorie 1" of "Rood"). En uiteindelijk een koppeltabel om de waardes aan de producten te koppelen.

Op die manier kan ik later gemakkelijk een eigenschap toevoegen zonder de hele database overhoop te moeten halen.

Alleen voor het opgeven van de afmetingen met bijhorende prijzen gaat dit niet lukken. Tenzij ik zoals ik bedacht had de waarden als volgt invoer: "10x15 2,50 euro" wordt dan "10|15|2,50".

Bij het opvragen van de afmetingen en prijzen zal ik dan per regel een explode moeten uitvoeren. En dat is wat me niet helemaal lekker zit. Volgens mij komt dit de performance niet ten goede.

De andere optie die ik toen bedacht had was om een aparte tabel aan te maken waarin ik de afmetingen en de prijzen zet en vervolgens ook koppel aan het product. Alleen dan is zonder omdat ik dan alsnog iets doe wat ik met de "universele" tabellen had willen voorkomen.

Dit is echt zo'n geval waarbij je een mening van iemand anders nodig hebt omdat je het zelf niet meer ziet.

is dit weer en database in een database gedachte ?

werkelijke waarde en, niet werkelijke waarde? .. je bent me kwijt
zowiezo een lijst met een andere maat is een ander product, klaar. Bindende eigenschappen kunnen dan een merk of een stijl kleur, etc... zijn. maar je moet 2 verschillende dingen niet 1 product noemen, daar ga je imho al de fout in


zowiezo het database in een database idee moet je laten varen

[Voutloos]

Saeverix schreef op zaterdag 02 juli 2011 @ 18:30:
Alleen voor het opgeven van de afmetingen met bijhorende prijzen gaat dit niet lukken. Tenzij ik zoals ik bedacht had de waarden als volgt invoer: "10x15 2,50 euro" wordt dan "10|15|2,50".

Bij het opvragen van de afmetingen en prijzen zal ik dan per regel een explode moeten uitvoeren. En dat is wat me niet helemaal lekker zit. Volgens mij komt dit de performance niet ten goede.

Performance is in eerste instantie niet het grootste bezwaar. Dat bezwaar is gewoon dat een dergelijk datamodel compleet ruk is.

Zie verschillende uitvoeringen gewoon als verschillende producten, of maak een 1:N relatie met versies/uitvoeringen. Alle producten hebben wel een formaat en prijs eigenschap, dus dat moeten gewoon specifieke kolommen met een proper datatype zijn.

[Avalaxy]

Ik zou gewoon een tabel Product maken met een aantal kolommen:

- Id
- Prijs exclusief BTW (let op dat je decimals gebruikt)
- Hoogte
- Breedte
- Diepte
- Gewicht
- Omschrijving
- Aantal op voorraad
- Referentie naar BTW code (die weer het percentage aangeeft)

Lijkt me het makkelijkst?

[Fish]

Aantal op vooraad is geen produckt eigenschap -> voorraadtabelletje

De prijs van een produkt kan veranderen over de loop der tijd het lijkt me handig om die apart te houden en daar datums aan te hangen, zowiso heb je verschillende prijzen inkoop/verkoop denk goed na wat je wil terug kunnen zoeken

[Avalaxy]

fish schreef op zaterdag 02 juli 2011 @ 20:25:
Aantal op vooraad is geen produckt eigenschap -> voorraadtabelletje

Eens.

De prijs van een produkt kan veranderen over de loop der tijd het lijkt me handig om die apart te houden en daar datums aan te hangen, zowiso heb je verschillende prijzen inkoop/verkoop denk goed na wat je wil terug kunnen zoeken

Niet eens, facturen hoor je imho gewoon in een aparte tabel te stoppen. De productomschrijving zou bijvoorbeeld ook kunnen wijzigingen. Dan maakt het helemaal niet meer uit wat je met je "product" doet, je facturen blijven altijd in de originele staat.

(aangenomen dat je daar op doelt trouwens)

[ Voor 3% gewijzigd door Avalaxy op 02-07-2011 20:28 ]

[Fish]

de facturen moet je zowiezo apart houden. maar het is handig om te weten wat het inkoop heeft gekost
(denk bijv aan de pricewatch)

[ Voor 13% gewijzigd door Fish op 02-07-2011 20:32 ]

[Avalaxy]

Ah, op die manier.

[Saeverix]

Ik zal het even verduidelijken: Het gaat om de verkoop van raamstickers. Daarbij heb je bijvoorbeeld de vorm "Eend". Van die vorm zijn bijvoorbeeld 8 verschillende maten te bestellen met dus 8 verschillende prijzen.

Om nu 8 keer het zelfde product toe te gaan voegen is niet echt praktisch. Daarom heb ik bedacht dat je 1 keer de basis informatie in moet vullen om vervolgens 8 keer de verschillende afmetingen met bijhorende prijzen in te vullen.

En daarom was mijn vraag. Een aparte tabel? Of de gegevens als producteigenschap toe voegen aan de bestaande 3 eigenschap tabellen.

[Joostje123]

Je zal toch ook nog een kolom kunnen toevoegen aan de categorie met daarin de prijs?
Dan krijg je dus:

Product:
Aantal kolommen

Tabel van je categorie:
Naam van je categorie
Prijs van de categorie

Koppeltabel

[Fish]

Saeverix schreef op zondag 03 juli 2011 @ 11:16:
Ik zal het even verduidelijken: Het gaat om de verkoop van raamstickers. Daarbij heb je bijvoorbeeld de vorm "Eend". Van die vorm zijn bijvoorbeeld 8 verschillende maten te bestellen met dus 8 verschillende prijzen.

Om nu 8 keer het zelfde product toe te gaan voegen is niet echt praktisch. Daarom heb ik bedacht dat je 1 keer de basis informatie in moet vullen om vervolgens 8 keer de verschillende afmetingen met bijhorende prijzen in te vullen.

En daarom was mijn vraag. Een aparte tabel? Of de gegevens als producteigenschap toe voegen aan de bestaande 3 eigenschap tabellen.

Niet echt praktisch daar kom je wel achter als je assortiment groter wordt.
of bedoel je vervelend om in te voeren met de hand ?

[Verwijderd]

Als ik kijk naar webshop systemen zoals Magento, dan zie ik dat één product meerdere variaties kan hebben (verschillende prijzen per aantal, per kleur, per grootte, etc), maar bijvoorbeeld ook per klant of klantgroep. En wanneer je naar de database structuur kijkt dan zul je zien dat een product niet in één tabel gepropt kan worden (bron: http://www.magentocommerc.../magento_database_diagram)

Misschien is het een idee om niet het wiel opnieuw uit te vinden en een bestaand systeem te gebruiken, of (wanneer het echt moet) heel goed kijken hoe en wat bestaande systemen werken.

[Saeverix]

Bijvoorbeeld categorie "Dieren" met daarin de 2 stickers "Eend" en "Paard". Waarvan elk 8 verschillende afmetingen beschikbaar zijn.

Ik wil dan niet 16 producten in die categorie hebben staan.
De bedoeling is dat zodra je een product selecteert er een dropdown box met daarin de verschillende afmetingen bij komt te staan. Vervolgens selecteer je de afmeting die je wilt en kun je het product aan je winkelmandje toevoegen.

Nou kan ik die 8 afmetingen als 8 losse producten toevoegen en laten zien als 1 product, maar dan kom ik mezelf ook met het bewerken van het product tegen. Dus dat is wat ik bedoel met niet praktisch.

De product eigenschap tabellen die ik gebruik is duidelijk? Of is de uitleg niet duidelijk genoeg geweest?

[L01]

Ik begrijp je bezwaar maar het is over het algemeen gebruikelijk om voor zoiets meerdere producten aan te maken, je hebt dan 1 hoofdproduct waarin je je tekst zet en je koppelt je varianten daar aan.

Zie bijvoorbeeld: http://www.kadowereld.nl/...ee/ernst---bobbie-t-shirt

Hier worden ook verschillende producten gebruikt, immers, elk product heeft een unieke productcode.


Neem ons advies ter harte en maak meerdere producten aan, dit zal zijn nut bewijzen.

De tekst updaten hoeft natuurlijk geen probleem te zijn, als je het gewoon zo maakt dat als je je hoofd product update dat dan gelijk je varianten worden meegenomen dan ben je er al.

Succes!

[Fish]

Waar ik vandaan kom werken we op drie niveaus

Product_group
Product_model (onderdeel van group)
Product_modelvariant (onderdeel van model) en dit is je dan echte produkt, 1 nummer (upc/ean) voor een uniek item

De rest is puur groupering voor andere onderdelen. facturatie, je webshop etc,

[Saeverix]

Ik zal even laten zien of ik jullie goed begrijp.

Momenteel heb ik het zo:

De property tabellen gebruik ik momenteel al voor de categorieën van een product en de kleuren die men kan bestellen.

Maar als ik jullie goed begrijp moet ik voor de afmetingen de producten tabel aanpassen naar het volgende:

Bij het toevoegen van een product met verschillende maten voeg ik dan eerst een entry toe met de basiseigenschappen(naam en dergelijke) ingevuld en vervolgens voor elke maat een entry met alleen de afmetingen, prijs en de Parent ID (ID van hoofdproduct met basiseigenschappen).

Bij een product met 4 maten komen er dan 5 entries in de tabel. 1 met het hoofdproduct en 4 met de afmetingen en prijzen.

Heb ik jullie op deze manier goed begrepen?

[Fish]

Nee,

Je moet geen kolom maken voor elke mogelijke eigenschap
maar een tabel met eigenschappen
e.g.

code:

Product  Prod_property Prod_prop_value

A        Height        0.2
A        Width         0.3
A        Weight        12
B        Height        10.29
B        Width         3.3
B        Weight        0.3

Zo kun je altijd extra/onvoorziene eigenschappen toevoegen, zonder je tabel bijv aan te passen

[ Voor 4% gewijzigd door Fish op 05-07-2011 14:36 ]

[Saeverix]

fish schreef op dinsdag 05 juli 2011 @ 14:31:
Nee,

Je moet geen kolom maken voor elke mogelijke eigenschap
maar een tabel met eigenschappen

Zo kun je altijd extra/onvoorziene eigenschappen toevoegen, zonder je tabel bijv aan te passen

Het idee wat ik in het bovenstaande plaatje al had dus. Een tabel met de eigenschappen, en een koppeltabel om de eigenschappen aan het product te koppelen.

Het punt is dat bij elke maat een eigen prijs hoort. En dat is op die manier moeilijk te koppelen. Dan zou er zeker weer een aparte koppeltabel voor de afmetingen en prijzen bij moeten...

[Fish]

Die discussie heb ik boven al gehouden. hoe jij database bouwd is uiteindelijk je eigen keus (los van wat goed of fout is)

[ Voor 5% gewijzigd door Fish op 05-07-2011 15:19 ]

[Saeverix]

Dat probleem zorgde er voor dat ik dit topic aangemaakt heb.
Hoe kan ik de eigenschappen tabel gebruiken voor de Afmetingen+prijs waarde. Daarom kwam ik op de oplossing met de explode functie. Beetje omslachtig, maar ik kon in combinatie met de eigenschappen tabel geen andere oplossing bedenken.

Ik kan de eigenschappen tabel gebruiken om Height, Width en Price apart in te voeren, maar dan kan ik de afmetingen en prijs niet bij elkaar houden. Of mijn denkvermogen moet me in de steek laten...

[Fish]

Jou probleem ligt gewoon bij het feit dat je 8 produkten 1 product wil noemen. En dat is best op presentatie niveau, maar niet in je database. dan moet in je produkt groepen gaan maken in je database

[ Voor 8% gewijzigd door Fish op 05-07-2011 15:58 ]

[CodeCaster]

Doe eens niet je prijzen in een float opslaan. Of: wat kost een product inclusief 19% BTW wat exclusief BTW € 42,50 kost?

[Saeverix]

CodeCaster schreef op dinsdag 05 juli 2011 @ 16:11:
Doe eens niet je prijzen in een float opslaan. Of: wat kost een product inclusief 19% BTW wat exclusief BTW € 42,50 kost?

Decimal is misschien beter inderdaad. Zul je dat merken qua performance?

[ Voor 19% gewijzigd door Saeverix op 05-07-2011 18:06 ]

[Avalaxy]

Saeverix schreef op dinsdag 05 juli 2011 @ 18:05:
[...]

Decimal is misschien beter inderdaad. Zul je dat merken qua performance?

Of je het nou merkt of niet: boeiend. Gewoon decimal doen, zoals ik je eerder ook al vertelde.

Mocht je performance willen kun je beter overstappen naar een compiled language (aangezien je het over Explode hebt neem ik aan dat je PHP gebruikt) dan micro-optimalisaties gaan lopen doen die je zwaar in de problemen kunnen brengen.

[Saeverix]

Ok duidelijk.

Alleen een oplossing voor mijn oorspronkelijke vraag is er nog niet echt. Hoe gebruik ik de eigenschappen tabel om de afmetingen met bijhorende prijzen toe te voegen?

Voorbeeld: 10x15cm 4,95 euro.
Daarvoor zijn 3 regels in de eigenschappen tabel nodig. Namelijk Width, Height en Price. Allemaal geen probleem. Maar hoe zorg ik er op een makkelijke manier voor dat die 3 regels bij elkaar blijven bij het uitlezen ervan. Een extra koppel tabel?

De makkelijke manier die ik had bedacht (alles in één regel en met Explode parsen) is mogelijk, maar omdat het niet een nette manier is heb ik dit topic geopend voor hulp.

[Voutloos]

Je beschrijft het van begin af eigenlijk al als 1 op veel relatie, dus maak dat er dan ook van.

[kwaakvaak_v2]

<pseudosql>
insert into eigenschappen set product_id = 1, product_property='width', product_value ='10x15';
insert into eigenschappen set product_id = 1, product_property='prijs', product_value ='4.95';
etc. etc.
</pseudosql>

En dan php gebruiken voor wat het kan, loosly typed variables. En anders moet je een tabel bij gaan houden met veldtypes waarin je bijhoud wat voor type veld het is. (beetje hoe bijvoorbeeld CCK in drupal het doet)

Oh en nokken met je druk te maken over performance, tegen de tijd dat je webshop amazon/bol achtige properties heeft, heb je met grote zekerheid voldoende budget om het dan op te lossen.

[Fish]

Saeverix schreef op dinsdag 05 juli 2011 @ 18:19:
Ok duidelijk.

Alleen een oplossing voor mijn oorspronkelijke vraag is er nog niet echt. Hoe gebruik ik de eigenschappen tabel om de afmetingen met bijhorende prijzen toe te voegen?

Voorbeeld: 10x15cm 4,95 euro.
Daarvoor zijn 3 regels in de eigenschappen tabel nodig. Namelijk Width, Height en Price. Allemaal geen probleem. Maar hoe zorg ik er op een makkelijke manier voor dat die 3 regels bij elkaar blijven bij het uitlezen ervan. Een extra koppel tabel?

Geen koppel tabel, en dan wordt het dus een script request. ga daar zelf ff wat moeite instoppen

hierarchie en scripts zijn 2 verschillen diciplines

[ Voor 10% gewijzigd door Fish op 05-07-2011 20:04 ]

[Saeverix]

Ik open de discussie even opnieuw. Zit namelijk nog met een reactie van Fish in gedachte.

Ik mocht zoals je zei niet 1 product van 8 producten maken. Mijn vraag is: Waarom niet? In werkelijkheid is het 1 product, alleen in verschillende maten. Productnummers spelen geen rol.

Net als dat je bijvoorbeeld kleurkeuze hebt in bepaalde winkels. Bij bepaalde kleuren (metallic bijvoorbeeld) heb je een hogere prijs. Er staat dan bijvoorbeeld "Metallic Silver (+ 3,00)" in een selectievak.

Ik ben namelijk na wat prutsen en nadenken op het volgende uitgekomen om het probleem van dit topic op te lossen. Ik bedacht me namelijk dat de breedte en hoogte niet gescheiden opgeslagen hoeven te worden.
En met de bovenstaande beschrijving in gedachte kwam ik op het idee om een eigenschap een prijs mee te kunnen geven.



Als dit echt "not done" is dan zou ik graag horen waarom. Het is dan voor mij ook weer een leermoment.

[ Voor 7% gewijzigd door Saeverix op 18-07-2011 17:06 ]

[vorlox]

Dat lijkt er al meer op alleen waarom nu die property values er nog bij ?
Ga je 1 value voor meerdere producten gebruiken?

[zeikmodus]
Verder wordt ik zelf altijd gek van die naamgeving product.
Ik heb altijd geleerd dat er een bepaalde hierarchy is.
(Niet vast maar even een voorbeeld)
Specialisme = Incontinetie
Subspecialisme = Absorberend
Productgroep = Luiers
Product =Ultra absorberende poepluier
Artikel = Ultra absorberende poepluier Small
Artikel = Ultra absorberende poepluier Medium
Artikel = Ultra absorberende poepluier Large
Verpakking = 1st
Verpakking = Binnendoos = 10 x 1st
Verpakking = Overdoos = 10 x 10st
Verpakking = Pallet = 50 x 100st

Zorg dat elke variatie een apart artikelnummer heeft..wel zo makkelijk met aanvragen van EAN nummers, tracking & tracing, barcodes enz
[/zeikmodus]

[Verwijderd]

Saeverix schreef op maandag 18 juli 2011 @ 15:47:
Ik mocht zoals je zei niet 1 product van 8 producten maken. Mijn vraag is: Waarom niet? In werkelijkheid is het 1 product, alleen in verschillende maten. Productnummers spelen geen rol.

Volgens mij zijn het toch degelijk 8 verschillende producten. Je betaald tenslotte een andere prijs voor elke sticker.

Om er even encyclo bij te halen..

14 definities op Encyclo
1) Een soort goederen met bepaalde kenmerken.

Je hebt stickers met kenmerken, de vorm is dan bv een appel(ja ik staar ff op een mac), maar dan heb je nog andere kenmerken, namelijk die afmetingen. En als dat verschilt, heb je ook een ander product.

Geen idee of het een nette oplossing is, maar misschien kun je een model opgeven als 'hoofdmodel'(de meest verkochte). De rest duid je dan aan als een subproduct en die laad je dan enkel indien nodig.

[Saeverix]

vorlox schreef op maandag 18 juli 2011 @ 21:03:
Dat lijkt er al meer op alleen waarom nu die property values er nog bij ?
Ga je 1 value voor meerdere producten gebruiken?

Ja want daar zitten ook de beschikbare kleuren in. De kleuren die geselecteerd kunnen worden wanneer er een product toegevoegd gaat worden. Anders kon die tabel inderdaad weg.

vorlox schreef op maandag 18 juli 2011 @ 21:03:
[zeikmodus]
...
[/zeikmodus]

Dat is zo gek nog niet. Dat van Product en Artikel was ik zelf niet op gekomen. Misschien het database ontwerp toch nog maar eens een keer op de schop nemen. Wil het namelijk wel zo goed mogelijk hebben voordat ik verder ga.

@JelmerHT: Jij ook bedankt voor de uitleg.

Jullie beide hebben me laten inzien dat het wel degelijk zin heeft om alle variaties als losse producten artikelen te zien. Bedankt!