 Ouwe rakker |
|
Ik zal eens even uitwerken hoe ik altijd mijn databases opzet voor een standaard webshop. Zal deze post zo updaten.
Order
+---------+-----------+---------+---------------+
| orderId | orderDate | userId | orderStatusId |
+---------+-----------+---------+---------------+
| INT (n) | DATETIME | INT (n) | TINT (2) |
+---------+-----------+---------+---------------+
Order +---------+-----------+---------+---------------+ | orderId | orderDate | userId | orderStatusId | +---------+-----------+---------+---------------+ | INT (n) | DATETIME | INT (n) | TINT (2) | +---------+-----------+---------+---------------+
De tabel order houdt voor mij precies bij welke orders er zijn geplaatst. Een order heeft een eigen uniek id. In dit geval heb ik geen lengte aangegeven voor de sleutel, maar dit kan je dan zelf aanpassen naar gelang je denkt dat de winkel veel/weinig te verwerken zal krijgen.
Van een order houd ik verder ook bij wanneer een order geplaatst is en voor welke gebruiker de order is. Als laatste houd ik ook een status bij van een bepaalde order. Deze statussen komen weer in een aparte tabel te staan, voor de volledigheid.
OrderStatus
+---------------+-------------+-------------+
| orderStatusId | title | description |
+---------------+-------------+-------------+
| TINT (2) | VARCHAR(32) | TEXT |
+---------------+-------------+-------------+
OrderStatus +---------------+-------------+-------------+ | orderStatusId | title | description | +---------------+-------------+-------------+ | TINT (2) | VARCHAR(32) | TEXT | +---------------+-------------+-------------+
De order statussen hebben een titel en een omschrijving. De titel kan iets zijn als; 'openstaand', 'geannuleerd', 'in behandeling', 'wachtend op antwoord klant', 'afgerond'. De omschrijving geeft gewoon wat meer informatie over die bepaalde status.
OrderRow
+---------+----------+-----------+---------------+---------------+
| orderId | row | productId | piecePrice | vat |
+---------+----------+-----------+---------------+---------------+
| INT (n) | TINT (2) | INT (n) | DECIMAL (7,2) | DECIMAL (4,2) |
+---------+----------+-----------+---------------+---------------+
OrderRow +---------+----------+-----------+---------------+---------------+ | orderId | row | productId | piecePrice | vat | +---------+----------+-----------+---------------+---------------+ | INT (n) | TINT (2) | INT (n) | DECIMAL (7,2) | DECIMAL (4,2) | +---------+----------+-----------+---------------+---------------+
De laatste tabel die ik in dit voorbeeld uitwerk is de OrderRow tabel. Hier staan de verschillende rijen in van de bestelling. Het orderId is samen met het veld row de primaire sleutel. Het orderId verwijst dus naar de order waar deze rij bij hoort, de row is gewoon het getal op welke positie deze thuishoort in de factuur. Hier dien je dus zelf even een getal aan te geven. Ik heb er dus voor gekozen om hier geen primaire sleutel aan te maken in de vorm van orderRowId. Dat is meer een persoonlijke keuze, natuurlijk ben je hier vrij in om dat anders te doen.
Het productId verwijst natuurlijk naar het product, de pieceprice is de prijs van één enkel product. Daarnaast geef ik per product ook aan wat het BTW tarief is. Waarom sla ik hier de stuksprijs en de btw op? Wat nu als ik dat niet deed.... volgend jaar gaat de BTW in nederland naar 20% (eerder was het 19%) en wie weet verander ik ook de prijs van een bepaald product wel eens. Op deze manier ben ik er zeker van dat al mijn facturen nog steeds in orde zijn en de juiste informatie weergeven.
Een dergelijk systeem kan je natuurlijk altijd uitbreiden met een systeem voor kortingen en wat niet meer. Ik heb dit eigenlijk ook net uit mijn mouw geschud, maar het zou je genoeg houvast moeten bieden om zelf iets op te zetten. |
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
Actiefste leden van de maand
