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.
Als je toch al gebruikt maakt van het RBAC waarom zou je dit dan niet doortrekken naar naar je cmsuser en webshopuser. Je user table moet niet meer bevatten dan een wachtwoord naam en andere vereiste criteria. Verdere adresgegevens koppel je hier aan door middel van andere tabellen.
Het is een kwestie van modelleren maar iedereen kleurt graag zelf de plaatjes zoals het supermarktmodel van Ozzie wat ik appels en peren vind. Een supermarkt heeft zijn personeelssysteem nooit op dezelfde applicatie als het klantensysteem en in het het geval van rickert gaat het kennelijk wel over dezelfde applicatie. Maar nogmaals, iedereen kleurt graag zelf de plaatjes en bouwt iets leuks.
?
Onbekende gebruiker
21-12-2014 11:47
Ik snap jullie allemaal. Alleen is het gemakkelijker om de 2 users te scheiden.
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?
>> Een supermarkt heeft zijn personeelssysteem nooit op dezelfde applicatie als het klantensysteem
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.
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
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 ...
?
Onbekende gebruiker
21-12-2014 15:36
gewijzigd op 21-12-2014 15:40
Is het misschien makkelijker om dit te doen?
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
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.
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.
?
Onbekende gebruiker
21-12-2014 16:06
Klopt, daar zat ik ook al overna te denken. Maaaaaarr...
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.
>> Hoe kan je dan meteen onderscheid maken tussen de verschillende adressen?
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 :)
?
Onbekende gebruiker
24-12-2014 17:37
@ozzie (en anderen)
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.
