Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien
Toon posts:

Database: productprijs en prijzen van bijbehorende opties

Pagina: 1
Acties:

Verwijderd

Topicstarter
Ik zit een beetje te dubben of ik wel de juiste manier gebruik voor de prijzen van producten in een database. Er zitten de volgende tabellen in de database:

Tabel 'item' (item_id, item_naam, item_prijs)
Tabel 'itemoptie' (itemoptie_id, itemoptie_prijs, maat_idfk, item_idfk)
Tabel 'maat' (maat_id, maat_naam)

Je kan dus producten hebben met een id, naam en een prijs. Je kan bijvoorbeeld product A van 20 euro invullen. Lekker makkelijk, je vult alleen tabel item in en klaar is kees. Het resultaat is:
A 20 euro

Maar producten kunnen ook extra opties hebben, zoals maten, met bijbehorende prijs. Zo kan er van product A een Large versie zijn van 22 euro en een XXL product A van 24 euro.

Zoals ik het nu heb gemaakt in mijn systeem wordt de normale item_prijs genegeerd en dus niet getoond indien er optieprijzen bestaan van het betreffende product. Dat heb ik gedaan omdat het 'basis' A product eigenlijk geen zin heeft om te tonen als er ook opties zijn, anders krijg je zoiets:
A 20 euro (deze tonen we dus maar niet, want zonder specificatie slaat het eigenlijk nergens op)
A Large 22 euro
A XLarge 24 euro

Een nadeel hiervan is dat als er opties zijn met bijbehorende prijzen, dat je dan eigenlijk al weet dat je voor nop de basisprijs aan het invullen bent. Wat wel handig is, dat als je op de basisprijs gewoon dezelfde prijs invult als de goedkoopste optie, dat je dan een makkelijke query hebt om in het overzicht van producten meteen de juiste prijs te tonen, je toont dan gewoon de prijs die bij basisprijs is ingevuld omdat die toch gelijk is aan de eerste optieprijs.

Wat ook nog zou kunnen is in de tabel 'item' de prijs weglaten. Dan moet je hem altijd moet invullen in de tabel 'itemoptie'. Misschien een beetje omslachtig als je veel producten hebt die toch helemaal geen opties en dus maar 1 prijs hebben.

Als ik naar OpenCart kijk, dan zie ik dat die een 'basisprijs' heeft in de producttabel. Maar die wordt niet genegeerd als er opties zijn van het product, die blijft altijd zichtbaar. Dan krijg je zoiets als:
A 20 euro
A Large +2 euro
A XLarge +4 euro
Maar dat vind ik raar, want wat voor een maat is de basis A dan van 20 euro? Dat ziet er niet echt handig uit dus dit vind ik een mindere manier.

Dus, wat is wijsheid? Moet ik het maar zo laten zoals ik het nu heb gemaakt, of zijn er nog betere ideeen?

  • pedorus
  • Registratie: Januari 2008
  • Niet online
Verwijderd schreef op vrijdag 08 februari 2013 @ 17:22:
Dan krijg je zoiets als:
A 20 euro
A Large +2 euro
A XLarge +4 euro
Maar dat vind ik raar, want wat voor een maat is de basis A dan van 20 euro?
Lijkt me Medium 8)
Dus, wat is wijsheid? Moet ik het maar zo laten zoals ik het nu heb gemaakt, of zijn er nog betere ideeen?
Hangt er een beetje vanaf of de basisprijs kan wijzigen zonder de opslagen. Beide systemen lijken me niet zoveel mis mee.

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten


Verwijderd

Prijzen steek je beter in een apart tabel.

3 tabellen :

- Artikel tabel: ArtikelId, ArtikelNaam, ...
- Artikel combinatie tabel: ArtikelId, CombinatieId, CombinatieNaam, ... (Dit is optioneel)
- Artikel prijs tabel: ArtikelId, CombinatieId (dit kan je leeglaten), prijs, hoeveelheid, start datum, eind datum, ...

  • _Erikje_
  • Registratie: Januari 2005
  • Laatst online: 20:50

_Erikje_

Tweaker in Spanje

Op mijn werk gebruiken wij hybris ecommerce. Deze heeft dit probleem netjes opgelost imho.

Wat hybris doet is hetvolgende, je hebt een generiek product die een aantal varianten heeft. Een generiek is bijvoorbeeld jas style a, een variant is die jas in maat M, in zwart. Varianten hebben een of meerdere prijzen.

Dit geeft je in de toekomst ook ruimte om afbeeldingen aan generieken te verbinden zonder fuss.

Verwijderd

Topicstarter
@ _Erikje_: Okee, maar waar zit de prijs in Hybris als er een product is zonder varianten? Klopt over die afbeeldingen, die doe ik al in een losse tabel, werkt goed. Varianten doe ik nu ook in een losse tabel met prijzen, alleen wat doe ik met die prijs uit de basisproducttabel.

Ja, wellicht is alle prijzen splitsen in een aparte tabel wat maartendm zegt wel het beste. Het lijkt me wel de netste oplossing eigenlijk, geen dubbele data voor de basisprijs. Al kost het dan iets meer moeite om de prijs op te halen want die staat dan niet meer in dezelfde tabel. Maar goed, mijn plaatjes staan ook al in een andere tabel. Ik weet alleen niet of de persoon die de producten moet gaan invoeren het leuk of handig zal vinden. :)

@ Pedorus: Het zou ook Small kunnen zijn. :) Ik kan het er in elk geval niet bijzetten in de titel anders krijg je:
A Medium 20 euro
A Medium Large 22 euro
A Medium XLarge 24 euro
Maar dat systeem van OpenCart met die opslagen vind ik sowieso niet handig. Ik vind het punt 1 niet mooi staan (ik toon liever meteen de echte prijs), en punt 2 maak je zoals je zegt de prijzen afhankelijk van elkaar als je met opslagen werkt.

Ik denk dat ik de prijzen maar ga splitten dan in een aparte tabel.

  • MueR
  • Registratie: Januari 2004
  • Laatst online: 20:03

MueR

Admin Devschuur® & Discord

is niet lief

Je hebt altijd varianten van een product, ook al is het er maar een. Dat is de makkelijkste manier om dit soort dingen te doen

Anyone who gets in between me and my morning coffee should be insecure.


  • TheNephilim
  • Registratie: September 2005
  • Laatst online: 21-11 15:31

TheNephilim

Wtfuzzle

Ook hier werken we op een dergelijke manier:

Product heeft productversies. Een productversie bestaat uit productvariatie. Een productvariatie is bijvoorbeeld Maat: S, M, L of Kleur: Groen, Geel, Rood. Bij een productversie selecteer je dan Maat: S en Kleur: Groen, dat samen is een productversie.

  • BramV
  • Registratie: Augustus 2007
  • Laatst online: 21-11 18:06
een model is uniek, prijs niet, dat zou je eigenlijk moeten normaliseren?

- misschien ook wel belangrijk hoe het bedrijf denkt bij het invoeren van prijzen: denkt / voert men in met basisprijs+opslag of totaalprijs

- met een aparte prijstabel kun je ook historie bijhouden: prijs_id, type_prijs (basis of optie), geldig vanaf
met type

  • TheNephilim
  • Registratie: September 2005
  • Laatst online: 21-11 15:31

TheNephilim

Wtfuzzle

Prijs is in een bepaald opzicht niet uniek nee, maar dat geld voor meer dingen die je eigenlijk toch per product(versie) wil opslaan. Prijs & btwcode is het enige wat je op moet slaan... Lijkt mij niet echt nodig om daar nu weer koppeltabellen en dergelijke voor te gaan maken.

Verwijderd

Topicstarter
BramV schreef op dinsdag 12 februari 2013 @ 09:44:
- misschien ook wel belangrijk hoe het bedrijf denkt bij het invoeren van prijzen: denkt / voert men in met basisprijs+opslag of totaalprijs
Zojuist toevallig nog over gehad met het bedrijf. Ze willen het liefste vasthouden aan hun eigen systeem met Excel en dan exporteren naar csv en vervolgens importeren in de webapp omdat in hun oude systeem al zoveel producten zitten. Dat kan dan nog een beetje lastig worden want ze hebben elk product en elke variant er los in staan, zoals (versimpelt):

EAN000100, Jas Style A, maat: S, kleur: groen, prijs: € 100,00
EAN000101, Jas Style A, maat: M, kleur: rood, prijs: € 100,00
EAN000102, Jas Style A, maat: L, kleur: rood, prijs: € 100,00
EAN000120, Jas Style B, maat: M, kleur: groen, prijs: € 120,00
EAN000125, Jas Style B, maat: XL, kleur: groen, prijs: € 125,00

Alles staat er dus dubbel in, niet echt genormaliseerd dus. En gemeenschappelijke velden zoals algemene info, kenmerken en plaatjes zitten er op dit moment ook nog niet in.

Van dit alles hadden ze me absoluut nog niets verteld. Ik ging ervan uit dat ze de webapp gewoon zouden gebruiken als hoofdsysteem. Dus dat wordt weer leuk, grrrrrrrrrr. :)

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Als bovenstaande het formaat is dan is het opzich goed te parsen ;)

Property's zijn gewoon gescheiden door dubbelepunt, met uitzondering van prijs.

Qua niet vertelde imports is dit toch echt zo ongeveer het makkelijkste wat ik ooit ben tegengekomen

Verwijderd

Topicstarter
Dit was dus maar even een simpele notatie/aanname van mij van een versimpelt stukje aantal records. ;)

Ik weet het bijna zeker, in het echie zal het er heel anders uit gaan zien. Of dit moet echt de eerste keer zijn dat het idd zo makkelijk zal zijn. Maar goed, ik wacht nu af op een echt stukje csv uit dat systeem.

// edit:
En inderdaad. Het wordt niet echt gemakkelijk aangeleverd, want de varianten als maten en kleuren hebben ze op dit moment gewoon in hun 'naam' field erbij ingevuld. Dus dan krijg je 25 keer dezelfde jas aangeleverd maar dan in 5 maten en 5 kleuren en dat verschil is dus alleen omschreven in het 'naam' veld, zonder enige samenhang, gewoon door elkaar gebruik van opties, volgorde, afkortingen en/of voluit.

Maar goed, ik ga nu eerst het systeem netjes opleveren zoals afgesproken. Daarna zien we wel met die import.

[ Voor 56% gewijzigd door Verwijderd op 12-02-2013 21:42 ]

Pagina: 1