Webshop database design 1.0

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: « vorige 1 2

Ger van Steenderen
Tutorial mod

Ger van Steenderen

24/12/2014 19:41:15
Quote Anchor link
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.
 
PHP hulp

PHP hulp

16/11/2024 19:34:20
 
Ozzie PHP

Ozzie PHP

24/12/2014 22:11:29
Quote Anchor link
>> 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.
 
Frank Nietbelangrijk

Frank Nietbelangrijk

25/12/2014 01:48:08
Quote Anchor link
Ozzie PHP op 24/12/2014 22:11:29:
>> 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.
 
Ozzie PHP

Ozzie PHP

25/12/2014 02:17:51
Quote Anchor link
>> 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?
 
Frank Nietbelangrijk

Frank Nietbelangrijk

25/12/2014 02:27:15
Quote Anchor link
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.
 
Ozzie PHP

Ozzie PHP

25/12/2014 02:45:14
Quote Anchor link
>> 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.
 

25/12/2014 04:22:09
Quote Anchor link
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.

Thanks phpers en goodnight!
 

Pagina: « vorige 1 2



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.