Ik ben bezig een webshop te bouwen in mijn CMS. Nu wil ik beginnen om de database voor webshop-users, orders en betalingen te ontwerpen.
Ik heb een aantal bedenkeningen voor de 1e stap, webshop-users.
Deze webshop-users kunnen inloggen op de website. Maar, het is ook gewenst door een andere klant van mij om een inlog te maken.
Wat stellen jullie voor? Alles 1 in DB gooien en op deze manier aangeven of de gebruiker dingen kan bestellen of gewoon elke user toegang hiertoe geven.
Je krijgt anders 3 soorten users in mijn database; cms-users (hebben toegang tot het cms en hieraan zijn rollen gekoppeld e.d) webshop-users (spreekt voor zich denk ik) inlog-user (dit kan voor afgeschermde content zijn)
Ik denk persoonlijk dat het beter is om de laatste 2 soorten users te combineren in 1 tabel.
---
Dan mijn 2e vraag, adresgegevens. Hoe kan ik dit het beste opslaan? Factuur en afleveradres is vaak gewenst maar moet niet verplicht zijn omdat ingelogde gebruikers die niet gebruikmaken van het webshop gedeelte het nodig hebben.
Ik zelf denk dat het opgeslagen kan worden in een tabel met adresgegevens o.i.d en dan deze linken aan een user.
Je zou je kunnen afvragen hoe groot de kans is dat op één adres meerdere bedrijven geregistreerd zijn.
Die kans is zeer klein, en om voor die uitzonderingen een koppeltabel te maken is wat overdreven.
Voor een op de consumenten markt gerichte webshop heb ik het afleveradres gekoppeld aan de bestelling, dat staat in een aparte tabel indien het afwijkt van het factuuradres.
>> Het opslaan van het standaard adres, waar zou jij dat neerzetten. Een adres moet via de koppeltabel aangegeven worden bij de user toch? Is het dan handig om het daarbij te zetten? Of bij de user tabel zelf.
Kun je iets duidelijker uitleggen wat je precies bedoelt? Ik snap je vraag niet helemaal.
>> Het opslaan van het standaard adres, waar zou jij dat neerzetten. Een adres moet via de koppeltabel aangegeven worden bij de user toch? Is het dan handig om het daarbij te zetten? Of bij de user tabel zelf.
Kun je iets duidelijker uitleggen wat je precies bedoelt? Ik snap je vraag niet helemaal.
een koppel tabel is enkel nodig bij een many to many relatie. Dat zou ik niet doen. Maar ik zou van de adressen wel een one to many maken dus een aparte tabel voor de adressen. een klant zou bij mij dan tot twee adressen kunnen koppelen en hiervoor zou ik gewoon twee foreign key kolommen in de customer tabel toevoegen. Of zeg ik dan iets heel vreemds? Die twee zijn dan overigens het afleveradres en faktuuradres. Meer heb ik niet nodig.
>> Die twee zijn dan overigens het afleveradres en faktuuradres.
Maar een bedrijf kan meerdere adressen nodig hebben. Wellicht dan geen koppeltabel, maar een aparte tabel met adressen met een foreign key als user id?
Ja een bedrijf kan meerdere vestigingen hebben. Maar hoe vaak ga jij het meemaken dat één iemand voor meerdere vestigingen gaat bestellen? Misschien ligt dat ook een beetje aan welke doelgroep je probeert te benaderen... Maar ga je een klant dan een keuzelijst voorschotelen van alle adressen die hij/zij al eens eerder heeft opgegeven? Hoeveel klanten zitten hier dan misschien ook juist niet op te wachten? (uit oogpunt van privacy) En hoe vaak zal het voorkomen dat al die filialen er een paar filiaalmedewerkers hun eigen account aanmaken?
Ik denk met adressen en telefoonnummers altijd maar zo: KISS, kort en simpel dus.
>> Maar hoe vaak ga jij het meemaken dat één iemand voor meerdere vestigingen gaat bestellen?
Ik heb bij een bedrijf gewerkt waar dit regelmatig voorkwam, dus zo vreemd is dat niet.
>> Ik denk ... altijd maar zo: KISS, kort en simpel dus.
Op zich een goede vuistregel, maar simpelheid is natuurlijk een relatief begrip en in dit geval gekoppeld aan o.a. de doelgroep en de gewenste functionaliteit.
?
Onbekende gebruiker
25-12-2014 04:22
Ik ben het met jullie allemaal zeer zeker eens.
De kans dat het gebeurd en gevraagd wordt is er, en ik wil dat voor zijn.
Ik zal een koppeltabel maken met de adressen en users. Deze kunnen ze per user zelf beheren en hergebruiken.
Het standaard adres zal ik aangeven met een aparte kolom zodat deze altijd als standaard wordt gepakt.
Jullie discussies e.d helpen me wel.
De shop komt al redelijk bij elkaar maar kan uiteraard nog velen maten beter en uitgebreider worden. De tijd zal het leren, ook de fouten natuurlijk haha.
