Citat:
Ursprungligen postat av mephisto73
Jag vill inte låta för besserwissig men en webshop är nog ett väl tufft första projekt, och i alla fall jag skulle nog rekommendera att du kodar ett par enklare projekt innan du ger dig på en webshop.
Du bör ha en ganska bra koll på relationsdatabaser innan du tar dig an ett sådant projekt.
Ett par tumregler (mina hemmaformulerade) vad gäller databasdesign är
- se en tabellrad med fält som en definition av en enhet och dess egenskaper, varje rad blir sedan en instans av enheten
- undvik att dubblera data i möjlligaste mån.
- dela upp aspekter i tabeller, d.v.s. bilder är en aspekt av produkt, men lämpar sig bäst som en separat tabell (du kanske vill ha flera bilder per produkt i framtiden, och då är det bra att inte hårdkoda antalet i db-strukturen).
Dock så är just order och orderrader ett litet undantag eftersom syftet med dem är ett annat. De behöver fungera som ett kvitto som visar vad kunder beställt, och det måste vara statiskt, d.v.s. det får inte ändras i framtiden även om du ändrar pris och produktnamn.
Kundvagnen kan däremot vara en "dynamisk tabell".
Sedan behöver du även tabeller för betalningar/transaktioner , leveransadress, returhantering osv.
|
Det finns massor av tabeller man måste tänka på, det är exempelvis Faktura/Fakturarad, det är inte samma sak som Order/Orderrad. Order behöver man inet spara för bokföringen, men faktura måste man spara för bokföringen.
Order och faktura är inte heller mappade 1:1 utan det kan finnas en order som genererar flera fakturor, beroende på att ordern var stor och inte kunde levereras samtidigt, men man vill som leverantör fakturera så fort man levererat. Då kan en order bli flera fakturor.
Sen finns det samfakturering dår man slår ihop flera små ordrar till en faktura.
Vi kan ta objektet Adress som är ett eget objekt i många sammanhang. I en faktura kan man behöva ange flera adresser, exempelvis Beställaren, Särskild leveransadress, och det finns även betalare som kan vara ett factoringbolag, då är vi uppei tre olika adresser, som är mycket vanligt.
Det kan även vara så att en kund delbetalar en faktura, pga av likviditetsbrist, då måste man kunna hantera alla betalningar för sig. En betalning mappar inte direkt 1:1 mot en faktura utan det kan vara flera betalningar på en faktura. Det kan även hända att en betalning avser flera fakturor, det måste man ta hänsyn till i databasen om man ska kunna hålla koll på kundreskontran eller leverantörsreskontran för den delen också.
Det finns ju även offert/offertrad.
Man ska skilja på produkt och pris då priset bör hanteras i en Prislista. En prislista består av många prislisterad. Varje prisrad ska ange priset för en produkt. Prislistan i sig har en viss giltighetstid från-/tilldatum. Varje kund kan ha ett eller flera Avtal och varje avtal har en koppling till en specifik prislista.
Som sagt så finns det massor av aspekter man måste tänka p åvid datamodellering. Men man måste börja ett par steg tidigare och skriva ner kraven som verkamheten ställer på systemet, sen ska man göra en knceptuell modell, dvs en mycket grov skiss över vilka verksamhetsobjekt som är involverade, man msåte ha koll på vilka användarroller som systemet ska betjäna (Exempelvis Webbkund och en administratör är exempel på två olika roller med olika behörighet i systemet.)
and on and on and on....