Webshop database design 1.0
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.
graag jullie adviezen en ervaringen hierbij.
Thanks :)
Ikzelf zou gewoon voor alle typen users een geheel RBAC-rechtensysteem maken, waarmee je kan bepalen wat ze wel/niet mogen. Dan kan je de rechten defineren in rechtensets die dan je koppelt aan de gebruikers.
Gewijzigd op 20/12/2014 19:08:33 door - Ariën -
Het is meer of ik 2 of 3 tabellen met users moet hebben.
webusers
cmsusers
Hiermee kan ik onderscheidt maken tussen 3 soorten gebruikers:
ingelogde gebruikers en webshop gebruikers
gebruikers voor het cms
Hopelijk begrijp je het nu een beetje.
Dus alle gebruikers in 1 tabel, en per gebruiker bepaald je wat voor gebruiker het is. Maar dan neig ik meer naar een RBAC-rechtensysteem om flexibeler erin te zijn.
Gewijzigd op 20/12/2014 19:42:39 door - Ariën -
Een webshop user kan ook een klant zijn en/of omgekeerd. Verder ga ik helemaal met Aar mee, dus RBAC
Kwestie van datamodellering en 3e normaalvorm. (Chris Date, boek 1 les 1 pagina 1 uitgave 1987)
Gewijzigd op 20/12/2014 20:29:44 door John D
De webusers, wat valt onder webshop user of ingelogde gebruiker voor een bepaald gedeelte.
En de CMS user waarmee toegang kan worden verkregen om de website te bewerken e.d
Beiden hebben (als ik Rickerst goed begrijp) een totaal andere functie. Webshop-users zijn front-end gebruikers en cms-users zijn back-end gebruikers. Op het moment dat je via de admin-login url inlogt, lijkt het me nutteloos om de complete klanten-tabel te controleren op username en password. Daarnaast zou een cms-user andere functionaliteit (en een andere databasemodel) kunnen hebben dan een front-end gebruiker. Dat je niet voor iedere TYPE cms-user/admin een andere tabel maakt, lijkt me logisch. Maar een onderscheid tussen cms-users en webshop-users lijkt me niet verkeerd.
Een cms user hoeft geen adres te hebben en is seperaat aan het frontend. We heb ik rollen en rechten toegekend aan de cms user.
Je kan daarna bij beide users van de rolverdeling uitgaan.
Maar wat is nu de beste manier om adressen te linken aan de webusers? Niet elke webuser heeft er 1 en sommige hebben er 2 vanwege het factuur en verzendadres.
De rollen die de cms users hebben kunnen gemakkelijk of helemaal niet samenwerken met de webusers.
Technisch gezien is het CMS en de frontend een aparte applicatie.
Elke hebben eigen models en controllers. Ook is het CMS een grote module waarin andere modules geladen worden.
Het supermarkt voorbeeld was perfect in mijn situatie. Andere applicaties zou ik zeer zeker zo bouwen als jullie zeggen. Alleen dit is gemakkelijker omdat frontend- en backend-users 2 conpleet aparte groepen zijn.
Ik zal bij beide de rollen gebruiken waar ik bij het cms dit al gebruik.
Thanks voor de hulp u allen. Alleen weet ik nog niet hoe ik de adressen kan koppelen voor de frontend users.
Hebben jullie hier nog suggesties voor?
Nee, maar er zijn zat pakketten die het eigen personeel en de klanten wel onder 1 applicatie draaien. Maar het is inderdaad een kwestie van persoonlijke voorkeur/smaak en specifieke toepasbaarheid.
>> Alleen weet ik nog niet hoe ik de adressen kan koppelen voor de frontend users.
Hebben jullie hier nog suggesties voor?
Dit vind ik ook wel lastig hoor. Ik denk dat je het beste met een koppeltabel kunt werken (hoewel ik ook geen database-expert ben, dus wellicht kan Ger van Steenderen hier z'n licht over laten schijnen).
Maar wat je dan krijgt is 1 tabel met de frontend users, 1 koppeltabel en 1 adres-tabel.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
frontend_users:
id voornaam achternaam
1 Rickert Bombaklats
front_end_users_adresses (koppeltabel):
id frontend_user_id type address_id
1 1 1 1
addresses:
id street number place zip_code
1 Grotestraat 1 Amsterdam 1234AB
id voornaam achternaam
1 Rickert Bombaklats
front_end_users_adresses (koppeltabel):
id frontend_user_id type address_id
1 1 1 1
addresses:
id street number place zip_code
1 Grotestraat 1 Amsterdam 1234AB
Bij de koppeltabel kun je dan bijv. type 1 gebruiken als factuuradres en type 2 als verzendadres. Het mooie van een koppeltabel is dat je oneindig veel adressen per gebruiker kunt toevoegen.
Wellicht zijn er nog betere mogelijkheden, dan horen we het graag uiteraard ...
Gewijzigd op 21/12/2014 14:19:59 door Ozzie PHP
Code (php)
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
frontend_users:
id voornaam achternaam postadres afleveradres
1 Rickert Bombaklats
1 1 1 2
addresses:
id street number place zip_code
1 Grotestraat 1 Amsterdam 1234AB
2 Kleinestraat 2 Rotterdam 4321BA
id voornaam achternaam postadres afleveradres
1 Rickert Bombaklats
1 1 1 2
addresses:
id street number place zip_code
1 Grotestraat 1 Amsterdam 1234AB
2 Kleinestraat 2 Rotterdam 4321BA
Het is namelijk ook zo dat niet elke website die ik maak dezelfde velden hebben.
Het is misschien ook gewenst door een klant om andere velden te hanteren. Mijn oude werkgever heeft die opgelost door dynamische velden te gebruiken waardoor je on-the-fly velden per klant kon opgeven die aan de users werden gekoppeld.
Bijvoorbeeld;
webuser_detail_fields
field_name
field_type
field_required
field_title
field_values
field_class
description
Dit komt letterlijk uit hun DB, geen idee waar name en title voor zijn. Ik nam aan label in het formulier en veldnaam.
Alleen is het dan weer zo dat de veldnamen niet multilanguage zijn en ik dit wel hanteer in mijn CMS.
Maar zo krijgen jullie een beetje een indruk hoe het in elkaar zit.
Dat is een persoonlijke keuze, maar besef je dan wel dat 1 persoon dus maar 1 postadres en 1 afleveradres kan hebben. Bij consumenten kom je daar meestal wel mee weg, maar bij bedrijven soms niet. Die hebben soms verschillende financiële afdelingen en verschillende panden (afleverlocaties). In jouw voorbeeld kom je dan dus in de knoop. Met een koppeltabel heb je dat probleem niet. Stel dat een bedrijf 6 afleverlocaties heeft, dan kun je die mooi in een drop-down menu tonen en op die manier kan het bedrijf snel de juiste locatie selecteren.
Hoe kan je dan meteen onderscheid maken tussen de verschillende adressen?
Het gaat me er nu vooral om dat de klanten gemakkelijk een alternatief adres kunnen opgeven, of kiezen bij het bestellen in de webshop.
Of is het dan gewoon zoals je zegt, een keuze of je het naar alternatief adres wilt sturen en dan 1 kiezen dmv een dropdown of invullen in het formulier.
En je kan dan zelf instellen bij een profiel wat je standaardadres is?
Is dat een optie die wellicht gemakkelijk kan werken. Ik houdt dan de structuur aan die jij aangaf Ozzie.
Met een select query waarbij je selecteert op "type", bijv. WHERE type=1. Waarbij 1 dan bijv. een factuuradres is en 2 een afleveradres.
Je moet even goed over nadenken wat voor een bedrijf makkelijk is. Stel ze typen de eerste keer een adres in, dan sla je dat op. De volgende keer toon je dat adres, maar zet je er ook een knop "nieuw adres toevoegen" bij. Zijn er meer dan 1 adressen ingevoerd, dan toon je bijv. het laatst gekozen adres, en toon je ook een drop-down menu waar dan dat andere adres in zit. Je kunt ook inderdaad een optie maken om een bepaald adres als standaard in te stellen. Je moet vooral zelf nagaan wat "handig" is in gebruik. Bedenk in je hoofd hoe jij het zelf handig zou vinden, of zet dat op papier. Vraag vervolgens aan een paar anderen of zij dat ook handig zouden vinden (misschien levert het tips op) en als dat zo is, dan ga je het zo maken :)
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.
Een bedrijf als bijvoorbeeld Philips heeft wel tig vestigingen. Als die iets kopen/bestellen/doen moet het niet afgeleverd worden op het hoofdkantoor. Daar moet de rekening (vaak) wel heen.