[alg] Database: Webshop met bezorgen en betalen

[Dennis]

Hallo,

Ik ben bezig met het ontwikkelen van een Webshop maar nu heb ik een vraag over bezorgen en betalen. Mijn doel is om beide zaken zo flexibel mogelijk te houden. Als we er vanuit gaan dat er drie verschillende bezorgmogelijkheden zijn (afhalen, bezorgen via TPG en bezorgen via UPS) en een stuk of acht verschillende betaalmogelijkheden (ideal, automatische incasso, zelf overmaken, rembours, etc.) dan wordt het voor mij qua database ontwerp erg ingewikkeld.

Een order heeft altijd één betaalmethode terwijl hij meerdere bezorgmethoden kan hebben (een order kan opgesplitst worden in meerdere bezorgingen, zoals bijvoorbeeld bij amazon.com). Nu heb ik zelf verschillende opties in gedachten:

• Een heleboel velden in de tabel 'Order' en 'Delivery' die allemaal ingevuld kunnen worden als dat nodig is. Dit veroorzaakt een heleboel nutteloze velden die soms misschien amper gebruikt worden. Tevens moeten er voor elke nieuwe methode weer velden bijkomen.

• Hetzelfde idee als hierboven maar dan voor elke methode een 1 op 1 relatie met de betreffende tabel. Voordeel is dat er nu niet honderden NULL values in de database komen. Nadelen blijven hetzelfde.

• Tabellen met betaalmethoden en bezorgmethoden en zowel daarin, als in de tabellen Order en Delivery een paar velden in beide tabellen die betrekking hebben op bepaalde functies (link naar webservices) en data (geserialiseerd xml). Nadeel is dat het uitwerken op client niveau naar bijvoorbeeld de velden die je moet aanmaken erg complex is. Het is wel erg flexibel.

Ik heb behoorlijk veel eisen, zoals het automatisch kunnen uitrekenen van bezorgkosten aan de hand van de gekozen bezorgmethode. Vandaar mijn idee voor webservices. Tevens moeten betalingen te tracen zijn, iets wat natuurlijk ook via webservices kan.

Tot nu toe kwam ik er redelijk uit met database ontwerp, maar nu loop ik echt vast. Heeft er iemand tips of kan iemand suggesties geven over bovenstaande uitwerkingen?

[bigbeng]

Een aantal tips die ik zo snel kan bedenken:

Orders opsplitsen in orderkop en orderregels.
Orderregels via een koppeltabel aan bezorging koppelen. Dit geeft je dan ook de mogelijkheid om bijvoorbeeld in 1 bezorging orderregels van verschillende orders te stoppen, dat kan misschien weer goedkoper zijn voor het bedrijf (gratis tip ).

Geen webservices gebruiken voor zaken die je geheel onder controle hebt. Webservices zijn mijns inziens bedoeld voor externe communicatie, dus om bijvoorbeeld een ander systeem met jouw systeem te laten praten. Bij webservices komt bovendien een overhead kijken die onnodig is (aanroepen van webservices gebruiken xml, niet het meest efficiente datatransport meganisme).
Je kunt wel interfaces definieren die een kostenberekenmodule moet implementeren bijvoorbeeld.

Succes met het samenstellen van je datamodel, ik vind het altijd een hele klus om flexibiliteit en werkbaarheid te combineren

[Eelke Spaak]

Ik zou iets pakken als:

code:

table Order:
 orderId
 paymentMethodId (references PaymentMethod)
 (...)

table Delivery:
 deliveryId
 orderId (references Order)
 deliveryMethodId (references DeliveryMethod)
 (...)

table Item:
 itemId
 deliveryId (references Delivery)
 (...)

table PaymentMethod:
 paymentMethodId
 (...)

table DeliveryMethod:
 deliveryMethodId
 (...)

Zo kan elke delivery in een order een aparte delivery method gebruiken, en is deze niet afhankelijk van de gebruikte payment method.

Edit: even ter verduidelijking misschien, er is dus een 1:n verhouding Order:Delivery en een 1:n verhouding Delivery:Item.

[ Voor 11% gewijzigd door Eelke Spaak op 22-10-2005 22:35 ]

[Dennis]

bigbeng schreef op zaterdag 22 oktober 2005 @ 14:50:
Orders opsplitsen in orderkop en orderregels.
Orderregels via een koppeltabel aan bezorging koppelen. Dit geeft je dan ook de mogelijkheid om bijvoorbeeld in 1 bezorging orderregels van verschillende orders te stoppen, dat kan misschien weer goedkoper zijn voor het bedrijf (gratis tip ).

Daar kies ik bewust niet voor, omdat het een hoop extra complexiteit met zich meebrengt m.b.t. zowel het boekhouden als met overzichten van orders.

Geen webservices gebruiken voor zaken die je geheel onder controle hebt. Webservices zijn mijns inziens bedoeld voor externe communicatie, dus om bijvoorbeeld een ander systeem met jouw systeem te laten praten. Bij webservices komt bovendien een overhead kijken die onnodig is (aanroepen van webservices gebruiken xml, niet het meest efficiente datatransport meganisme).
Je kunt wel interfaces definieren die een kostenberekenmodule moet implementeren bijvoorbeeld.

Die interfaces is een heel goede tip! Daar had ik zo snel nog niet eens aan gedacht. Betekent wel dat ik voor elke betaalmethode / bezorgmethode aparte klassen moet maken. Of dat echt een probleem is weet ik nog niet, immers, als je alle betaalmogelijkheden in je applicatie stopt hoeft er in principe niks meer te wijzigen. Maar ondersteuning voor alles is wel complex natuurlijk .

Succes met het samenstellen van je datamodel, ik vind het altijd een hele klus om flexibiliteit en werkbaarheid te combineren

Ja, ik ook .

Eelke Spaak schreef op zaterdag 22 oktober 2005 @ 22:34:
Ik zou iets pakken als:

code:

knip

Zo kan elke delivery in een order een aparte delivery method gebruiken, en is deze niet afhankelijk van de gebruikte payment method.

Edit: even ter verduidelijking misschien, er is dus een 1:n verhouding Order:Delivery en een 1:n verhouding Delivery:Item.

Yep, dit is ook zoals ik het nu heb. Betaalmethoden zullen worden gekoppeld aan een order, terwijl bezorgmethoden aan een bezorging worden gekoppeld. De vraag van het topic was meer waar je bepaalde data m.b.t. een betaling of bezorging opslaat, want elke betaling heeft zijn eigen velden die je wilt opslaan.

[DukeMan]

Dennis schreef op zondag 23 oktober 2005 @ 15:56:
Die interfaces is een heel goede tip! Daar had ik zo snel nog niet eens aan gedacht. Betekent wel dat ik voor elke betaalmethode / bezorgmethode aparte klassen moet maken. Of dat echt een probleem is weet ik nog niet, immers, als je alle betaalmogelijkheden in je applicatie stopt hoeft er in principe niks meer te wijzigen. Maar ondersteuning voor alles is wel complex natuurlijk .

Het lijkt me sowieso handig om elk betaalmiddel apart te doen in bijvoorbeeld een soort plugin systeem. Dit is handig wanneer je bijvoorbeeld een extra betaalmiddel wilt hebben, er wordt gestopt met de de ondersteuning ervan (net als bij bv way2pay) of je manier van communiceren met de servers van de betaaldienst moet aangepast worden. Dan kun je dat mooi per module doen.
Ik heb dit op dezelfde manier gedaan, en dit werkt erg prettig