|
|
 | Strukturering af tabeller til webshop
Fra : Peter Farsinsen |
Dato : 19-09-05 17:14 |
|
Hej
Jeg skal omskrive en eksisterende webshop, da der er opstået et behov
for at kunne sælge mere end én type produkter ;)
Den nuværende tabelstruktur er helt plain, dvs. alle oplysninger i én
tabel, hvor tomme felter er 0 eller NULL. Den stil har jeg selvføligelig
ikke lyst til at videreføre, men jeg er lidt i tvivl om, hvad 'best
practice' mht. til design af tabeller til formålet.
Anyway, som det er nu, forestiller jeg mig nedenstående tabeller, de
problemer jeg umiddelbart ser følger bagefter.
PRODUKTGRUPPER:
id
navn
PRODUKTER:
id
navn
prod_grp_id
vaegt
foto
pris
PRODUKTEGENSKABER:
id
prod_id
egenskab
value
Tabellerne 'produktgrupper' og 'produkter' giver forhåbentlig sig selv.
'Produktegenskaber' regner jeg med skal indeholde supplerende
oplysninger, f.eks. at et produkt (en sweatshirt f.eks.) er grøn og
størrelse XL, på den måde bliver løsningen forhåbentlig dynamisk. Feltet
'egenskab' kunne evt. indeholde et id, der henviser til en tabel med
mulige egenskaber, men det er ik' centralt her.
Det der er mit problem er, at f.eks. en sweatshirt, der findes i tre
størrelser og i tre farver vil resultere i ni forskellige produkter.
Sådan skal det selvfølgelig ikke fremstå i webshoppen, så de skal på en
eller anden vis grupperes. Jeg kunne selvfølgelig have en overordnet
tabel (Produkgruppering), der henviser til yderligere en tabel
(Produkter) der indeholder produkterne, men vil det give mening og være
korrekt i forhold til de produkter, der kun fås i en farve/størrelse?
Jeg håber, at I kan hjælpe mig men et godt forslag.
- Peter
| |
 Lars Balker Rasmusse~ (19-09-2005)
| Kommentar
Fra : Lars Balker Rasmusse~ |
Dato : 19-09-05 17:38 |
|
Peter Farsinsen <fornavn@efternavn.dk> writes:
> Det der er mit problem er, at f.eks. en sweatshirt, der findes i tre
> størrelser og i tre farver vil resultere i ni forskellige produkter.
> Sådan skal det selvfølgelig ikke fremstå i webshoppen, så de skal på en
> eller anden vis grupperes.
Hav en "option" og en "value" tabel, som indeholder:
Option: "Størrelse", "Farve", osv
Value: "L", "XL", "grøn", "rød", osv
Hav så en "produktattribut" tabel, der peger på et produkt, en option
og en value. Desuden skal du tænke på evt. pris- og vægtforskelle.
Disse kan også gemmes i denne attribut-tabel.
Pris og vægt er du nødt til at have i hoved-produkt-tabellen, da nogle
produkter netop ikke har nogle atributter at vælge mellem.
Håber det gav mening.
--
Lars Balker Rasmussen Consult::Perl
http://consult-perl.dk
| |
Peter Farsinsen (19-09-2005)
| Kommentar
Fra : Peter Farsinsen |
Dato : 19-09-05 17:45 |
|
Lars Balker Rasmussen wrote:
> Håber det gav mening.
Jo, tak men så langt er jeg imidlertid med. Måske fremgik det ikke af
mit indlæg, men jeg troede i al fald, at det var tydeligt, da jeg skrev det.
Problemt er ikke, hvordan jeg skal håndtere 'ekstra' egenskaber, men
derimod, hvordan jeg skal håndtere flere produkter, der gerne skulle
fremstå som et enkelt. Jeg kan selvfølgelig tilknytte flere egenskaber
til ét produkt, så som størelserne S, M, L, XL osv., men da løsningen
gerne skulle holde styr på lagerantal er den løsning ikke holdbar. Det
glemte jeg dog at nævne i mit første indlæg :/
Håber I kan følge problemstillingen...
- Peter
| |
Martin Christensen (19-09-2005)
| Kommentar
Fra : Martin Christensen |
Dato : 19-09-05 19:45 |
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Peter Farsinsen <fornavn@efternavn.dk> writes:
> Problemt er ikke, hvordan jeg skal håndtere 'ekstra' egenskaber, men
> derimod, hvordan jeg skal håndtere flere produkter, der gerne skulle
> fremstå som et enkelt.
Lad det være flere rækker i din produkttabel, men tilføj en kolonne
'produkt_id', som angiver produkt, så alle dine delprodukter
(forskellige størrelser og farver af trøjer i dit eksempel) kan
identificeres ved denne. Så kan du gruppere eller hente detaljeret
produktinformation alt efter ønske.
Jeg har i øvrigt lagt mærke til, at du giver alle tabeller en
id-kolonne uanset behov. I de fleste tilfælde ville jeg vælge en
naturlig nøgle i stedet.
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG < http://www.gnupg.org>
iEYEARECAAYFAkMvBzMACgkQYu1fMmOQldXZEQCfQfDnAv+mlLw/ijd+Qody9op5
27gAn2u4W2BHC1ppfNS7YGMkkkgJmcTl
=cnUd
-----END PGP SIGNATURE-----
| |
 Peter Farsinsen (19-09-2005)
| Kommentar
Fra : Peter Farsinsen |
Dato : 19-09-05 20:05 |
|
Martin Christensen wrote:
> Lad det være flere rækker i din produkttabel, men tilføj en kolonne
> 'produkt_id', som angiver produkt, så alle dine delprodukter
> (forskellige størrelser og farver af trøjer i dit eksempel) kan
> identificeres ved denne. Så kan du gruppere eller hente detaljeret
> produktinformation alt efter ønske.
Tak forslaget, det lyder som en god løsning.
> Jeg har i øvrigt lagt mærke til, at du giver alle tabeller en
> id-kolonne uanset behov. I de fleste tilfælde ville jeg vælge en
> naturlig nøgle i stedet.
Jeg er ikke helt spids i normalisering af databaser - hvilket den
opmærksomme sikkert har opdaget ;) Anyway, vil da vende normalformerne
endnu en gang, inden jeg koder videre.
Tak for hjælpen!
- Peter
| |
|
|