---

Jeg er igang med at bygge en shop løsning, og sidder nu og tænker over
hvordan jeg får bygget den bedst mulige db struktur mht produkter, priser,
lagerstatus mm.

Opgaven er:
Et produkt kan indeholde mange varianter. Fx. Kan eet produkt eksisterer i 3
forskellige farver, hvoraf der er en uafhængig pris for hver. Oveni dette
kan hvert produkt også have forskellige tilknytnings produkter som også
giver en anden pris.

Eksempel:
Produktet er en mobiltelefon, Nokia 3210. Denne Nokia findes i Rød, Blå og
Orange.
Nokia 3210 Rød kan købes med Telia abb, TDC abb og uden abb.
Nokia 3210 Blå kan købes med TDC og Debitel abb.
Nokia 3210 Orange kan kun købes uden abb.

Alle overstående har hver for sig en pris og en lagerstatus. Dvs. Nokia 3210
Rød med TDC koster 500,- og der er 3 på lager. Nokia 3210 Rød med Telia
koster 100,- og der er 10 på lager ... osv.

Dertil kommer at der fx. også kan blive solgt en lampe som der ikke skal
sættes farve på og ikke har nogle tilknytnings produkter. Den skal
selvfølgelig også have en pris og en lagerstatus.

Håber nogle af jer har en god løsning. Mit mål er at få så få tabeller som
muligt, og jeg er overbevist om det er muligt. Min hjerne kører dog i
selvsving når den skal finde en god løsning.

På forhånd tak.

---

On Thu, 04 Nov 2004 00:02:00 +0100, Hansen wrote:

> Mit mål er at få så få tabeller som muligt

Er der en dybere mening bag det mål?

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

>> Mit mål er at få så få tabeller som muligt
>
> Er der en dybere mening bag det mål?

Jeg ved selvfølgelig ikk med Hansen, men plejer det normalt ikke være
for at det bliver mere overskueligt, og for at spare plads hvis man
f.eks. har sin hjemmeside til at ligge på ex. B-One...


--
Simon Moore Højer

At programmere er at dykke ned i det hav af muligheder,
alle tiders hurtigst ekspanderende teknologi tilbyder.
Citat: Jakob Kristiansen (Start på visual basic 6.0)

---

> Jeg ved selvfølgelig ikk med Hansen, men plejer det normalt ikke være for
> at det bliver mere overskueligt, og for at spare plads hvis man f.eks. har
> sin hjemmeside til at ligge på ex. B-One...

Lige præcis

---

Simon Moore Højer wrote:
>>> Mit mål er at få så få tabeller som muligt
>>
>> Er der en dybere mening bag det mål?
>
> Jeg ved selvfølgelig ikk med Hansen, men plejer det normalt ikke være
> for at det bliver mere overskueligt, og for at spare plads hvis man
> f.eks. har sin hjemmeside til at ligge på ex. B-One...

Overskueligheden kan vi hurtigt blive enige om.
Pladsmæssigt, kan det dog være en god idé at designe så man undgår
dobbelt-data eller formår at dele noget andet data, hvilket kan give flere
tabeller men mindsker størrelsen.

--
Mvh
///JJ

---

>> Mit mål er at få så få tabeller som muligt
>
> Er der en dybere mening bag det mål?
>

Det er simpelthen for at holde det overskueligt. Jeg har tidligere lavet en
løsning ala. det der er beskrevet, men når jeg kigger på den idag så er den
meget uoverskueligt lavet, og man skal en mere kompleks sql query igennem
bare for at hive en pris ud på et produkt.

Det må kunne gøres mere simpelt?

---

On Thu, 04 Nov 2004 10:05:04 +0100, Hansen wrote:

>>> Mit mål er at få så få tabeller som muligt
>>
>> Er der en dybere mening bag det mål?
>
> Det er simpelthen for at holde det overskueligt.

Det er umuligt at forestille sig en nogenlunde virkelighedsnær model, der
på samme tid har få tabeller og er på 3. normalform og uden alt for
mange NULL-kolonner.

Hvor agressivt du vil normalisere, er op til dig. Du risikerer som bekendt
forskellige anomalier, hvis du ikke normaliserer i passende omfang.

> Jeg har tidligere lavet en
> løsning ala. det der er beskrevet, men når jeg kigger på den idag så er den
> meget uoverskueligt lavet, og man skal en mere kompleks sql query igennem
> bare for at hive en pris ud på et produkt.

Hvis du tænker dig godt om, når du skaber modellen (og vælger en
passende navnekonvention), kan du ofte gøre din SQL relativt simpel ved
at benytte join-udtryk såsom "USING" og "NATURAL LEFT JOIN" til at skære
ned på længden af SQL-udtrykkene. Hvis du så samtidig benyttede et
databasesystem med views, kunne du gøre tingene ekstra lette for dig selv.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Hej Troels,

> Det er umuligt at forestille sig en nogenlunde virkelighedsnær model, der
> på samme tid har få tabeller og er på 3. normalform og uden alt for
> mange NULL-kolonner.

Jeg går heller ikke med tanker om at jeg får proppet det hele ned i en tabel
.... så virkelighednær er jeg dog. ;) Løsningen jeg tidligere har lavet
består af ikke mindre end 5 tabeller. Det syntes jeg måske er i overkanten.

> Hvor agressivt du vil normalisere, er op til dig. Du risikerer som bekendt
> forskellige anomalier, hvis du ikke normaliserer i passende omfang.
>
> Hvis du tænker dig godt om, når du skaber modellen (og vælger en
> passende navnekonvention), kan du ofte gøre din SQL relativt simpel ved
> at benytte join-udtryk såsom "USING" og "NATURAL LEFT JOIN" til at skære
> ned på længden af SQL-udtrykkene. Hvis du så samtidig benyttede et
> databasesystem med views, kunne du gøre tingene ekstra lette for dig selv.
>

Databasen er MSSQL, så views som jeg forstår det er ikke noget problem. Men
jeg tror du snakker for hurtigt for mig, JOIN kender jeg til, men jeg ved
ikke hvad du mener når du siger at hvis min db benytter "views" fx.?
Kan du udbyde for en novice?

---

"Hansen" wrote

> Jeg går heller ikke med tanker om at jeg får proppet det hele ned i en
> tabel ... så virkelighednær er jeg dog. ;) Løsningen jeg tidligere har
> lavet består af ikke mindre end 5 tabeller. Det syntes jeg måske er i
> overkanten.

5 tabeller er ingenting
Hvis vi snakker om > 100 tabeller så er der en sjat at holde styr på

> Databasen er MSSQL, så views som jeg forstår det er ikke noget problem.
> Men jeg tror du snakker for hurtigt for mig, JOIN kender jeg til, men jeg
> ved ikke hvad du mener når du siger at hvis min db benytter "views" fx.?

Du bruger normalisering og logik til implemterng af dit datagrundlag
Efterfølgende opbygger du et passende set af views til præsentation af data

Gennem views kan du samle dine tabeller i logiske dele og fx afgrænse dele
af tabellerne der bruges til andre ting

Prøv at kikke igennem manualen til MSSQL (BOL) omkring views

- Peter

---

On Thu, 04 Nov 2004 12:00:13 +0100, Hansen wrote:

> Databasen er MSSQL, så views som jeg forstår det er ikke noget problem.

Ups, sorry: Jeg havde af uvisse grunde fået indtryk af, at du benytter
MySQL (MySQL har ikke views).

Med MSSQL kan du benytte views til at simplificere ofte udførte queries,
eller til at dele komplicerede queries op i form af views, som du så
skaber overskuelige queries fra.

Hvordan MSSQL har det med opdatérbare views ved jeg ikke lige. Med views
kan det ofte betale sig som udgangspunkt at tænke på dem som read-only.

Desværre understøtter MSSQL ikke joins med USING(...) eller NATURAL ...,
så den slags tricks kan du ikke benytte dig af til at simplificere dine
forespørgsler.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Hansen wrote:
> Jeg er igang med at bygge en shop løsning, og sidder nu og tænker over
> hvordan jeg får bygget den bedst mulige db struktur mht produkter, priser,
> lagerstatus mm.

Jeg gemmer "statisk" produktinfo i en XML-struktur, som ligger i
databasen, det synes jeg giver en meget flexibel model, hvor jeg ikke er
begrænset af databasen. Det gælder bare om at finde sig selv en
XML-model som overholder alle de krav som man har.

Jeg lægger bare XML'en ind i min Product-class, som kan hente de
nødvendige ting ud med noget xml-query osv..

Om det er en god løsning ved jeg ikke, men den virker som den skal

Nogen der har en mening om det ?

--
/Anders

--------------------------
Eksempel:

<produkt>
   <titel>
      <dk>Tape</dk>
      <de>Isolier Band</de>
      <eng>Electro Tape</eng>
   </titel>
   <beskrivelse>
      <dk>1 rulle Sort, 15 mm. Bred og 10 m lang</dk>
      <de>1 Rl. Schwarz, 15 mm. Breit und 10 m lang</de>
      <eng>1 Pcs Black, Width 15 mm. Lenght 10 m.</eng>
   </beskrivelse>
   <kortbeskrivelse>
      <dk></dk>
      <de></de>
      <eng></eng>
   </kortbeskrivelse>
   <billede>
      <dk>tape.jpg</dk>
      <de>tape.jpg</de>
      <eng>tape.jpg</eng>
   </billede>
   <subtitel>
      <dk></dk>
      <de></de>
      <eng></eng>
   </subtitel>
   <vaegt>10</vaegt>
   <pris>10</pris>
   <fragtgruppe>0</fragtgruppe>
   <produktskema></produktskema>
   <forhandler>
      <forhandlerprodukt>1</forhandlerprodukt>
      <pris>
      <valg>
         <titel>1 stk</titel>
         <pris>345</pris>
      </valg>
      </pris>
      <produktid>10-100-50</produktid>
      <begraensning>
         <min_antal>100</min_antal>
      </begraensning>
   </forhandler>
   <begraensning>
   </begraensning>
</produkt>
------------------------------

---

(Gensendt indlæg: Den forrige udgave af indlægget burde være cancelled,
men der kan være news-software, der ikke understøtter cancelling.)

On Thu, 04 Nov 2004 13:27:02 +0100, Anders Matthiessen wrote:

> Jeg gemmer "statisk" produktinfo i en XML-struktur, som ligger i
> databasen, det synes jeg giver en meget flexibel model, hvor jeg ikke er
> begrænset af databasen.

Hvordan synes du, at databasen begrænser dig?

> Nogen der har en mening om det ?

Jeg mistænker, at du
1. Ikke kan opnå samme grad af referentielle (og andre)
constraints som du kan i en løsning, der kun benytter
datatyper, som DBMSet har god "forståelse" for.
2. At du ikke ikke kan opnå samme performance som med
en normaliseret løsning, selv hvis kun én operation
udføres ad gangen. Og ved flere samtidige operationer
har du antagelig (og forhåbentlig) skrivelåst adgang til
relevante XML-data, hvorfor samtidighed da må blive
meget dårlig.
3. At du ikke ligeså let kan dele data mellem din
eksisterende frontend og anden software: Andelen af
software, der kan arbejde med skalare værdier i et
DBMS, overstiger voldsomt andelen, der forstår din
særlige konstruktion.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Troels Arvin wrote:

> Jeg mistænker, at du
> 1. Ikke kan opnå samme grad af referentielle (og andre)
> constraints som du kan i en løsning, der kun benytter
> datatyper, som DBMSet har god "forståelse" for.

Det er selvfølgelig rigtigt.. Formålet med XML-filen er, f.eks. hvis man
har et ubegrænset antal sprog, slipper jeg for at have en tabel med de
enkelte oversættelser i de enkelte sprog. Data som skal kunne tilgås af
databasen selv ligger udenfor.

> 2. At du ikke ikke kan opnå samme performance som med
> en normaliseret løsning, selv hvis kun én operation
> udføres ad gangen. Og ved flere samtidige operationer
> har du antagelig (og forhåbentlig) skrivelåst adgang til
> relevante XML-data, hvorfor samtidighed da må blive
> meget dårlig.

Dataerne bliver kun læst, og hvis der bliver skrevet er det alligevel
kun 1 fast bruger. Hvad angår performance, er det ikke den største
butik(er) som det bliver brugt på, og umiddelbart synes jeg at det går
"hurtigt nok" :)

> 3. At du ikke ligeså let kan dele data mellem din
> eksisterende frontend og anden software: Andelen af
> software, der kan arbejde med skalare værdier i et
> DBMS, overstiger voldsomt andelen, der forstår din
> særlige konstruktion.

Nu har jeg ikke andet software som skal læse daterne, end shoppen og
programmet som jeg redigerer produkterne i.

Men det er selvfølgelig en masse begrænsninger på brugen af min metode,
men på den anden side synes jeg at jeg får en god flexibilitet, der gør
at jeg ikke skal ændre en masse ting i databasen, hvis modellen skal
over til en hel ny butik med andre krav

Jeg siger tak for analysen :)

/Anders

---

Hansen wrote:
> Jeg er igang med at bygge en shop løsning, og sidder nu og tænker over
> hvordan jeg får bygget den bedst mulige db struktur mht produkter,
> priser, lagerstatus mm.

Der findes mindst én open source shop-løsning til Linux (kan ikke huske
navnet), måske du kan hente brugbar inspiration der. Det er i hvert fald
virkelighed og ikke kun teorier.


--
Mvh
///JJ

---

Har jeg ikke ret i, at stort set alle informationer (pris, lagerstatus,
osv.) knytter sig til hver enkelt variant af produktet? I så fald kan du
nøjes med én tabel.

Nokia 3210 Rød er ét varenummer og Nokia 3210 Blå er et andet. Den
farveløse lampe er et tredie.

Der skal naturligvis være et felt, der identificere et fællesskab mellem
alle de mange nokia 3210'er. Lad os kalde det produktnummer. Da
null-værdier er uønsket, skal den farveløse lampe også have et
produktnummer. Der er bare ikke andre varenumre med samme produktnummer.
Vi har altså et produkt med kun én variant.

Tilknytningsprodukter kan laves ved at tilføje et felt, der henviser til
et produktnummer, som dette varenummer er tilbehør til. En bedre løsning
er dog en særskilt tabel. For så kan en vare være tilbehør til mange
produkter. Fx. er en Sony Ericsson bordstander brugbar til mange
modeller af telefoner. Den særskilte tabel skal kun indeholde
tilknytningen mellem to varenumre.

Hvis du skal have en produktbeskrivelse med specifikationer mv. kan du
jo lave en tabel til dette med produktnummer som primær nøgle.

Mere kan jeg ikke se der er brug for ifølge din beskrivelse. Tre tabeller.

--
Jan Fjeldmark mailto:janf@janf.dk http://janf.dk/
Hvad du end tror du er, så er du altid meget mere.