hvordan lage en produkt database

[demiurgen]

jeg vil lage en produkt database for en webshop.

noen som vet hvordan en slik db kan se ut (med tabeller)??

kan en db se slik ut:

 

PRODUKT (varenr, beskrivelse, pris)

DETALJER (ID, varenr, størrelse, vekt, etc...)

 

hvordan ser f.eks databasen til komplett.no ut?? noen som vet?

hvordan deler jeg opp databasen??

hvor mye bør databasen deles opp?

bør hvert produkt ha sin egen tabell slik:

 

STØVSUGERE (varenr, vekt, sugeevne)

MP3_SPILLERE (varenr, størrelse, vekt, minne)

 

noen som kan hjelpe meg å få dette så riktig som mulig?

[laaknor]

PRODUKT (varenr, beskrivelse, pris)

DETALJER (ID, varenr, størrelse, vekt, etc...)

 

legg inn en VAREKATEGORI (ID,navn), + varekategoi i PRODUKT, så ville jeg vært fornøyd.

[demiurgen]

TAKK!

 

så det er ikke mer som skal til?

 

er det slik de fleste webshopper har organisert sine databaser?

men blir det ikke mange tomme felter i DETALJER tabellen?

 

hvis støvsugere har et felt for sugeevne så vil jo det stå tomt for mp3spillere...?

Endret 15. juni 2006 av demiurgen

[laaknor]

så det er ikke mer som skal til?

Det er det sikkert, men det er sånn jeg ville designet det

 

er det slik de fleste webshopper har organisert sine databaser?

 

Jeg vil tro det

 

men blir det ikke mange tomme felter i DETALJER tabellen?

hvis støvsugere har et felt for sugeevne så vil jo det stå tomt for mp3spillere...?

 

Når jeg tenker meg om, så ville jeg ha fjernet den, og lagt inn detaljene i PRODUKT-tabellen. Du behøver ikke å fylle ut noe informasjon i alle kolonnene. Litt av poenget er å ha færrest mulig spørringer.

[roac]

Når jeg tenker meg om, så ville jeg ha fjernet den, og lagt inn detaljene i PRODUKT-tabellen. Du behøver ikke å fylle ut noe informasjon i alle kolonnene. Litt av poenget er å ha færrest mulig spørringer.

6312003[/snapback]

All den tid et produkt kan ha flere egenskaper, er jeg ubetinget uenig med deg. Det vil være en stor fordel å kunne ha dette i en egen tabell, det vil blant annet muliggjøre søk på produkter der en bestem egenskap har eller inneholder en bestem verdi. Som f eks:

 

select * from products p where categoryid = (select categroy id from categories where type = 'dvd') and exists (select * from features where (id = p.id) and (type = 'formats') and (value like 'XViD'))

 

Dette er ikke like lett å få til dersom du hiver alt inn i et tekstfelt, bl a fordi en glup selger da plutselig legger inn teksten "NB! Støtter ikke XViD".

 

Med fornuftig indeksering er det fremdeles snakk om så få tabeller at spørringene bør gå raskt.

[j000rn]

Måten Roarc vil gjøre dette på er ganske omdiskutert. Fordelen med den er at det er veldig enkelt å implementere. Bakdelen er hastighet. Uansett bør du legge til de mest vanlige detaljene rett inn i Products tabellen, f.eks. Price, Color?, Weight, Size, Manufacturer, etc... (også avhening av hvilke produkter butikken skal selge)

 

Og ikke bruk sub-selectes. Bruk join.

 

En mange-til-mange relasjon til Categories ville jeg også hatt. F.eks. en usb disk som også kan spille MP3; skal den ligge under "USB Disker" eller "MP3 Spillere"? LCD skjerm som også har TV-tuner; "Dataskjermer" eller "TV"?

[tZar]

Måten Roarc vil gjøre dette på er ganske omdiskutert. Fordelen med den er at det er veldig enkelt å implementere. Bakdelen er hastighet. Uansett bør du legge til de mest vanlige detaljene rett inn i Products tabellen, f.eks. Price, Color?, Weight, Size, Manufacturer, etc... (også avhening av hvilke produkter butikken skal selge)

6314028[/snapback]

 

Hmm, farge, produsent osv burde vel ikke ligge rett inn i produkt tabellen, men med en fremmednøkkel. Man skal ikke trenge å skrive samme data mange ganger.

 

Forøvrig støtter jeg helt klart joines og ikke sub-queries.

[j000rn]

Hmm, farge, produsent osv burde vel ikke ligge rett inn i produkt tabellen, men med en fremmednøkkel. Man skal ikke trenge å skrive samme data mange ganger.

6314059[/snapback]

 

Enig, det gikk bare litt raskt her

 

Jeg ville også hatt en litt bedre krav-spec før jeg begynte å modelere databasen. F.eks. hva med forskjellige "farger" på samme produkt? Forskjellige "farger" på samme produkt med ulik pris? Forskjellige produktnummer men *samme produkt* om det er forskjellige "farger"?

("farge" som et eksempel, kanskje "farge" også byttes ut med flere detaljer?)

 

Og ikke minst krav til belastning. På en høyt besøkt webshop ville jeg nok vurdert å legge flere av detaljene i Products tabellen, mens på en liten butikk uten alt for mye besøkende latt mer ligge i andre tabeller ved siden som Roac foreslo.

Endret 15. juni 2006 av jorn79

[roac]

Måten Roarc vil gjøre dette på er ganske omdiskutert. Fordelen med den er at det er veldig enkelt å implementere. Bakdelen er hastighet. Uansett bør du legge til de mest vanlige detaljene rett inn i Products tabellen, f.eks. Price, Color?, Weight, Size, Manufacturer, etc... (også avhening av hvilke produkter butikken skal selge)

 

Og ikke bruk sub-selectes. Bruk join.

 

En mange-til-mange relasjon til Categories ville jeg også hatt. F.eks. en usb disk som også kan spille MP3; skal den ligge under "USB Disker" eller "MP3 Spillere"?  LCD skjerm som også har TV-tuner; "Dataskjermer" eller "TV"?

6314028[/snapback]

Omdiskutert, tja. Alle mine kilder i hvert fall sier at man skal normalisere etter 3NF, og så skal man evt denormalisere etter behov i etterkant. Jeg har enda ikke sett en eneste kilde som sier at man skal designe etter noe annet enn 3NF. At man kanskje ender opp med noe annet, det får så være.

 

Nå skriver jeg også stort sett joins i steden for subqueries (noe jeg vel har gjort ganske klart i dette forum tidligere), koden var rett og slett et eksempel på hva man be om av informasjon. Nå er vel også MySQL noe mer hårsår på hvordan du skriver spørringer enn det Microsoft SQL Server er. Uten at jeg selv har testet de opp mot hverande har jeg ved gjentatte anledninger fått presisert hvor dårlig query optimizer til MySQL er i forhold til Microsoft SQL Server (eller Oracle/DB2/UDB/Sybase for den saks skyld).

 

Videre så er problemet med normalisering når det blir mange tabeller og mye trafikk. Da kan denormalisering lønne seg, men man skal også være klar over at det for store mengder data kan være en vesentlig ytelsesmessig genvist med normalisering, siden mengden data kan bli kraftig redusert. Så for å sende ballen tilbake, å denormalisere på et tidlig stadium er veldig omdiskutert

[j000rn]

Jeg sier jo ikke at man ikke skal normalisere etter 3NF, men det du foreslår er noe helt annet. Med den metoden så lager man en "ny generisk database" i databasen. Jeg har selv gjordt det på samme måten flere ganger og kommer til å gjøre det igjen også. Jeg er både for og imot begge måtene, og beregner dette opp mot kravene til løsningen som skal lages. Men man bør tenke litt over hva man faktisk gjør når man lager databasen på den måten...

 

http://asktom.oracle.com/pls/ask/f?p=4950:...:10678084117056

[roac]

Og ikke minst krav til belastning. På en høyt besøkt webshop ville jeg nok vurdert å legge flere av detaljene i Products tabellen, mens på en liten butikk uten alt for mye besøkende latt mer ligge i andre tabeller ved siden som Roac foreslo.

6314082[/snapback]

På en webshop med høy belastning hadde jeg cached sidene, slik at det var statiske sider som blir sendt til bruker. Dette lar seg ganske enkelt gjøre. Man vil fremdeles ha en liten appikasjon som sjekker om produktet er oppdatert, men det er en vesentlig mindre krevende jobb.

 

Forøvrig så vil jeg påpeke at jeg i SQL Server 2005, IBM UDB 9 og Oracle i nyere versjon (vet ikke helt når støtten kom der) ville kikket næremere på datatypen XML, for å se om slik informasjon kanskje passer bedre som XML. Jeg er litt i tvil med tanke på spørringer mot farge, men heller likevel til at det kan bli et god løsning, såfremt man har gode indekser.