19. juni 2006 - 11:40Der er
17 kommentarer og 1 løsning
Feedback på databaseopbygning?
Hej,
Jeg er ved at lave en prissammenlignings-database og har lavet en foreløbig skitse med følgende tabeller:
Producent: ProducentId Producent ProducentURL
Kategori: KategoriId Hovedkategori Underkategori
Produkt: ProduktId ProducentId KategoriId Model Specifikationer ImageURL
Forhandler: ForhandlerId Firmanavn Adresse Postnr By Telefon Telefax E-mail Web-site SE Kontaktperson KP-mail KP-telefon Brugernavn Password
Prisliste: PrisId ProduktId ForhandlerId Lager Leveringstid Fragt Pris Ialt Vis
Der mangler sikkert en hel masse og derfor vil jeg meget gerne have respons eller forslag til ændringer da jeg er ved at gå lidt sukkerkold. Især i forhold til relationer. Spørgsmålet er også om jeg kan gøre det mere simpelt uden at det går ud over funktionaliteten. Jeg vil for alt i verden undgå at lave en forkert opbygning, da jeg går udfra, at det kan komme til at koste mange timer.
Hvordan sikrer jeg mig (jeg mener i opbygningen) at databasen evt. kan flyttes til en anden platform i fremtiden?
Krav: 1. Forhandler skal kunne tilmelde sig via formular, der efterfølgende skal godkendes. Derefter tildeles forhandleren et brugernavn og password. 2. Det skal være så smertefrit så muligt for forhandleren at opdatere pris/produkter. 3. Besøgende på siden skal kunne søge på specifikt produkt (laveste pris), producent, underkategori eller produkttype og meget meget mere. 4. Jeg tænker på at lave endnu en tabel (produktspecifikationer i en mere detaljeret udgave). 5. Søgninger skal gerne kunne vises i en tabel i browser. Meningen er at disse data skal skrives ind i CSS tabeller.
Skal jeg vælge MSSQL eller er MYSQL nok i første omgang.
Mht. databasevalg: Det bliver helt klart rarest for dig selv at vælge en database og så holde dig til den database. Det bliver irriterende for dig at starte med MySQL og derefter migrere til MSSQL. Der skal konverteres data og lukkes for systemet så der ikke skrives til databasen imens osv... Om det er MySQL eller MSSQL skal jeg ikke gøre mig klog på - personligt vil jeg pege på MSSQL, men det kommer an på hvor mange samtidig brugere (og penge) du har :-)
Mht. databasemodellen: 1) Kategori - hvad består hoved og underkategori af? Er de boolske/bit værdier. Var det ikke nemmest at indsætte en parentID, som peger på overkategorien (sæt til 0 hvis hovedkategori).
2) Kan et produkt fremgå i flere kategorier - det er man tit og ofte interesseret i. I så fald skal der laves en intersection tabel imellem produkt og kategori. Hvis ikke - så bare set bort fra dette punkt.
3) Husk at tilføje en bolsk/bit værdi i forhandler som f.eks. hedder godkendt, som default er 0 og sættes til 1 når det er godkendt.
4) Husk forhandlerID i produkt-entiteten, således man ved hvilken forhandler "ejer" hvilke produkter.
5) Kan et produkt ikke have flere producenter... i så fald så skal du lave om på fremmednøglen imellem de to entiteter. Hvis ikke, så bare se bort fra dette pkt.
1. mht. Kategori kan det f.eks. være Computere -> Bærbare eller Netværk -> Netkort. mht. parentID, som peger på hovedkat. Kan du vise mig et eksempel? 2. Nej et produkt kan ikke indgå i flere kategorier. 3. Er hermed gjort se forslag 1 og 2. 4. Er gjort. 5. Jo et produkt kan godt have flere producenter. Jeg er i tvivl om hvad jeg præcis skal ændre?
Jeg har lavet 2 forslag nu:
Forslag 1:
Producent: ProducentId Producent ProducentURL
Kategori: KategoriId Hovedkategori Underkategori
Produkt: ProduktId ProducentId KategoriId ForhandlerId Model Specifikationer ImageURL
Forhandler: ForhandlerId Firmanavn Adresse Postnr By Telefon Telefax E-mail Web-site SE Kontaktperson KP-mail KP-telefon Brugernavn Password Godkendt: 0
Prisliste: PrisId ProduktId ForhandlerId Lager Leveringstid Fragt Pris Ialt Vis
Forslag 2:
Producent: Navn URL
Kategori: Hoved Under
Produkt: ID ProducentNavn KategoriHoved KategoriUnder ForhandlerNavn Navn Beskrivelse Specifikationer ImageURL
Forhandler: Navn Adresse Postnr By Telefon Telefax E-mail Web-site SE Kontaktperson KP-mail KP-telefon Brugernavn Password Godkendt
Pris: Id ProduktNavn eller ProduktId??? ForhandlerNavn ??? Lager Leveringstid Fragt Pris Ialt Vis
Jeg er i tvivl om jeg skal lave 2 tabeller mere til M:M relationer: Pris/produkt relation? Pris/forhandler relation?
ad 1: Du tilføjer en attribut ved navn ParentID - du laver en reference til kategoriID. Det er faktisk ikke værre end det :-)
ad 2: Ok
ad 3: ser fint ud.
ad 4: ok
ad 5:
Et produkt kan have flere producenter og en producent kan producere flere produkter. Derfor er der tale om en mange-til-mange relation, derfor skal du indsætte en intersection tabel, som udelukkende indeholde referencer til produkt og producent:
Fornemt. Men hvorfor har den en N:M mellem pris og produkt. Der er selvfølgelig et hensyn at tage hvis du gerne vil se på prisudvikling over tid, i så fald skal din pris tabel indeholde gyldigfra og gyldigtil.
beef12: Hvilket forslag synes du bedst om? 1 eller 2? M:M mellem pris og produkt fordi en pris kan henvise til flere produkter(med samme pris) og fordi samme produkt kan have flere priser. Men ellers er prisudvikling over tid en god feature :) Jeg har prøvet at finde alle M:M relationer i første omgang. Derefter kan jeg så begynde at sortere. Men lige nu skal jeg finde ud af de søgninger, der normalt vil blive foretaget for så at sætte index de mest hensigtsmæssige steder.
Der misforstår du lidt det smarte ved N:M-relationer. Ganske rigigt kan flere produkter have samme pris, men så er det således at du i princpiet skal fylde din pris tabel med samtlige priser der er mulige... og det er ret mange !
Jeg synes bedst om løsning2, dog uden en mange-til-mange mellem og produkt. Desuden synes jeg at du burde bruge den fremgang at du får historisk data i pristabellen - altså ved at indsætte gyldigfra og gyldigtil. gyldigtil skal bare være NULL hvis det er den nuværende pris.
Jeg synes også selv bedst om forslag 2. Jeg har fjernet M:M relation mellem pris og produkt.Mht. parentID har jeg forsøgt men er ikke sikker på det er OK.
Forslag 2
Producent: Navn URL
Kategori: ID (PK) ParentID Hoved Under
Produkt: ID (PK) KategoriHoved (FK) KategoriUnder (FK) Navn Model Specifikationer ImageURL
Forhandler: ID (PK) Navn Adresse Postnr By Telefon Telefax E-mail Web-site SE Kontaktperson KP-mail KP-telefon Brugernavn Password Godkendt: 0
Pris: Id (PK) Pris Fragt I alt Lager Leveringstid Vis Gyldigfra Gyldigtil 0
ParentID peger så på ID, så ved man altid hvilken kategori er underkategori til hvad. Så er der lige en undtagelse... Hvis ParentID = 0, så er det så en hovedkategori.
Hov hov - lige en sidste ting. Forhandlere kan oprette egne kategorier ikke? For hvis det er rigtigt, så skal der eno ikke være en intersection tabel imellem forhandler og kategori - til gengæld skal der være en fremmednøgle til forhandler i kategori-tabellen.
Mht. At forhandlere kan oprette egne kategorier er sikkert en god ide, men jeg er ikke helt sikker på at det jeg ønsker. Mht. til ParenrId mener jeg at have forstået det nu. F.eks, vil en UnderUnderUnderkat vil have parentID 8, ikke? Tak for eksemplet og MSSQL syntaksen.
Her er et rev. forslag 2:
Producent: Navn URL
Kategori: ID (PK) Navn ParentId (FK til KategoriID) ForhandlerID (FK)
Produkt: ID (PK) KategoriNavn (FK) Navn Model Specifikationer ImageURL
Forhandler: ID (PK) Navn Adresse Postnr By Telefon Telefax E-mail Web-site SE Kontaktperson KP-mail KP-telefon Brugernavn Password Godkendt: 0
Pris: Id (PK) Pris Fragt I alt Lager Leveringstid Vis Gyldigfra Gyldigtil 0
ID Navn ParentID 1 kategori1 0 2 kategori2 0 3 underkat1 1 4 underkat2 2 5 underunderkat 4
Nej ikke rigtigt. En underunderunderkat vil have parentID = 5, idet pager på underunderkat som har kategoriID = 5.
Modellen ser fin ud. Dog bør du nok slette ialt-feltet fra pris-tabellen. Beregn du hellere den on-the-fly. Ellers skal du beregne den hver gang brugeren ændrer pris, fragt osv...
Rettelse: Nej ikke rigtigt. En underunderunderkat vil have parentID = 5, idet den peger på underunderkat som har kategoriID = 5 eller en hvilken som helst underunderkat - nu bruger jeg den som eksempel da det er den eneste der lige eksisterer i dette datasæt.
Ok, så har jeg forstået princippet med Id - parentID. Jeg siger tusind tak for hjælpen :) Jeg har slettet PrisProdukt og nu også PrisForhandler samt I alt.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
