[MySQL] Ontwerpen van een database

[Verwijderd]

Goedemorgen mede-tweakers,

Laat ik bij het begin beginnen en de situatie uitleggen.

Ik leer momenteel voor applicatie-ontwikkelaar en op mijn stage moet ik een behoorlijke grote applicatie ontwikkelen zoals ik nu zal omschrijven:

Wat de bedoeling is, dat jij per gemeente kan 'shoppen'. Je hebt per gemeente één persoon die accounts aanmaakt voor verschillende winkels in de gemeente, als klant zal je vervolgens alle winkels in jou gemeente kunnen bekijken.

Jij als klant registreert je, je kiest je gemeente en vult wat persoonlijke gegevens in. Klaar.
Ik, of een 'beheerder' van de gemeente maakt accounts aan voor de verschillende winkels in een gemeente.
De winkel, zal vervolgens zijn shop kunnen vullen.

Als jij als klant inlogt zul je vervolgens een overzicht krijgen van alle winkels in je gemeente (die op de site staan) en je kunt alles van die winkels in één winkel mandje gooien en in één keer afrekenen. Ik moet vervolgens zorgen dat ik weet hoeveel (in aantallen en in euro's) er bestelt is bij die winkels.

Nu heb ik het volgende al in Access gemaakt, maar ik heb er zo mijn twijfels bij. Het word een behoorlijk grote database in ervaring met zoiets heb ik nog niet, dus ik hoopte op wat hulp van de tweakers hier.

Klik erop voor een grote versie:


Nu vraag ik niet aan jullie om de database af te maken (ik verwacht ook niet dat iemand dat zou doen ), maar wat voor fouten zien jullie gelijk al en hoe begin ik met het maken van zo'n grote database?


EDIT:

Ik heb een nieuwe database gemaakt.

[ Voor 5% gewijzigd door Verwijderd op 22-04-2011 13:46 ]

[KabouterSuper]

'k moest even grinniken bij je opmerking dat je het een grote database vindt....pas vanaf een tabel of 200 zou ik de term "groot" in de mond durven nemen.

Wat betreft je dataontwerp even snel wat korte gedachten:
* wat is het verschil tussen winkel_id en shop_id?
* wat is het verschil tussen gemeente_id en klant_id?
* wat is de bedoeling van de kolom product_id in shop?
* je categorien zijn denk ik niet handig gedefinieerd. Hangt een categorie aan een winkel? Zo nee, hoe kom je er dan achter welke categorien aanwezig zijn in welke winkel?

[CH4OS]

Ik ben niet echt een SQL-expert, maar ik kan zo heel weinig relaties leggen, ik begrijp dat de pijltjes relaties zijn, maar ik zie zo 1 2 3 niet wáármee ze een relatie leggen.

EDIT:
Ik zie ook relaties lopen tussen franchiser en gemeentes, maar mij is niet geheel duidelijk waarvoor dat dan is.

[ Voor 26% gewijzigd door CH4OS op 09-04-2011 10:51 ]

[Verwijderd]

Tabellen login en klant schrappen, vervangen door een tabel "gebruiker" met de eigenschappen van beide tabellen.
Kolom "login_id" van franchiser schrappen.
Koppeltabel toevoegen voor koppelingen tussen "gebruiker" en "franchiser".
Tabel "shop" schrappen.
Kolom "shop_id" van "product" moet zijn "winkel_id".

Verder zie ik redelijk wat beperkingen op het gebied van uniekheid van producten en categorieën. Daar zijn kennelijk al keuzes in gemaakt. Wie onderhoudt de categorieën? Kan een product in slechts één winkel worden besteld?

[Precision]

• Tabel 'shop' heeft geen meerwaarde, schrappen

  Tabel "shop" schrappen.
  Kolom "shop_id" van "product" moet zijn "winkel_id".

• Zoals ik het nu zie, heeft een winkel/franchiser 1 login terwijl ik mij kan voorstellen dat er meerdere mensen werken en dat sommige winkels/franchisers elke medewerker een unieke login willen geven. Maak een extra tussentabel en link die. Oké er staat in je omschrijving 1 persoon (maar zie m'n voetnoot, soms is het onderdeel van het vak om de opdracht te veranderen, wees erop voorbereid), zoals hier boven omschreven is beter. Als extra voordeel kun je meerdere mensen toevoegen op een winkel.

  Tabellen login en klant schrappen, vervangen door een tabel "gebruiker" met de eigenschappen van beide tabellen.
  Kolom "login_id" van franchiser schrappen.
  Koppeltabel toevoegen voor koppelingen tussen "gebruiker" en "franchiser".

• Is je bestelling_details nu niet afhankelijk van een bestelling? Hoe krijg je nu de prijs bij een product te zien? Als ik het goed heb hou je rekening met het feit dat de factuurprijs kan verschillen met de actuele prijs. Maar hoe weet een product nu de actuele prijs?
• Er wordt nergens rekening gehouden met een mogelijke korting en het type korting.
  Type korting kan zijn dat als een klant bvb +15 producten besteld hij x aantal korting krijgt en bij +25; y aantal korting etc
• Zijn de prijzen in alle winkels gelijk? Als winkel X product Y meer verkoopt zouden ze bvb een actie kunnen opzetten. Het lijkt me handig om overal dezelfde product omschrijving te hebben, maar een tussentabel tussen de winkel en het product met daarbij de prijs als het onder dezelfde franchise valt.
• Een categorie heeft maar 1 cat_img?
  Maak een extra tabel afbeelding en link cat_img erheen en zorg dat product ook afbeelding(en) kan hebben
• klant_naam, wat als je een klant moet opzoeken op bvb familienaam? Misschien gescheiden opslaan? Je kunt ze nog altijd tonen als select voornaam + ' ' + naam as 'klant_naam'
  Misschien handig om al je namen zo te doen?
• Je bent niet consistent in je adres (franchiser heeft oa postcode, klant krijgt er nog eens plaats bij, terwijl plaats = gemeente?), omvat het adres ook al de postcode en de gemeente?
• Hoe ga je om met internationalisering? Er gaat een vestiging open in een buurland. Hoe ga je om met de prijs van een product? Valuta?
• Waarom stop je gemeente_provincie als string in je tabel gemeente? Oké je moet ergens een lijn trekken en niet te ver gaan normaliseren, maar dan zou ik gemeente_provincie ook in een apparte tabel plaatsen.
• Welke functie heeft gemeente_id bij login? Je gaat er nu vanuit dat je altijd als klant inlogd? Een franchise is niet gelinkt aan een gemeente en heeft ook een login_id. Zoals eerder vermeld maak een tabel "gebruiker" en smijt gemeente_id weg, heb je niet nodig.
• Als er niet betaald is, dan is je tabel betaling leeg dus heb je geen betaling_status, ik zou dit bij bestelling plaatsen.

Hoe zeker ben je van je opdracht? Zou het kunnen dat een deel van het vak is dat ze midden in het semester plots de opdracht veranderen en willen dat je meerdere 'beheerders' etc kunt hebben. Je maakt dit programma waarschijnlijk voor een klant en in de praktijk wil een klant ook nog al eens van gedacht veranderen, daar reken jij extra voor door, maar als je er al rekening mee had gehouden...
Hoe groot een tabel is, is natuurlijk relatief
Wat ik hier neerzet is enkel maar mijn interpretatie, ik zou er je opdracht voor moeten zien en vragen kunnen stellen aan je docent om dingen uit te sluiten, maar dit jouw taak

[ Voor 13% gewijzigd door Precision op 10-04-2011 00:53 ]

[Verwijderd]

ziet er goed uit.

[afraca]

Decompositie in bijvoorbeeld BCNF of 3NF zijn leuke tutorials voor. Vreemd dat mensen altijd maar losse entiteiten in een tabel gooien, er een <tabelnaam>id veld ingooien, en als ze nog leuk bezig zijn wat foreign keys erbij gooien.

Stel een lijst op met al je gewenste attributen. Genereer hierbij een set F met daarin al je functional dependencies. Bereken de minimal cover G van F. Voor elke FD X --> a1, a2, an maak je een tabel X(PK), a1, a2, an . Als je dan nog resterende attributen over kijk je even 17 seconden rond naar een global key.

[tss68nl]

Precision schreef op zondag 10 april 2011 @ 00:43:
Hoe zeker ben je van je opdracht? Zou het kunnen dat een deel van het vak is dat ze midden in het semester plots de opdracht veranderen en willen dat je meerdere 'beheerders' etc kunt hebben. Je maakt dit programma waarschijnlijk voor een klant en in de praktijk wil een klant ook nog al eens van gedacht veranderen, daar reken jij extra voor door, maar als je er al rekening mee had gehouden...

Jij rekent helemaal niets extra door voor wijzigingen die de klant aanbrengt, tenzij je alles al tot in de puntjes vast had liggen. Kortom, we mogen er van uit gaan dat alles met de klant al 100% is doorgesproken en vastgelegd, en dat TS precies weet wat de klant wil. Zo niet, dan hoort hij nog geen datamodellen te bouwen

Verder is het datamodel wel heel erg klein. Ik kan je vertellen dat wil je een goede vastlegging van verkopen/omzet/marge in zulk een complexe omgeving als verschillende winkels in verschillende gemeentes, die allemaal verschillend assortiment hebben en toch gezamenlijk afrekenen.... je waarschijnlijk een 200 tot 300 tabellen database nodig hebt om alle gegevens daadwerkelijk vast te leggen. Denk daarbij aan retouren, derving, korting (incidenteel, set, actie,inkoop), onderlinge leveringen, inkoop, etc. Ik neem dan ook aan dat deze opdracht een erg beperkte scope heeft, en dat enkel de checkout van de producten wordt vastgelegd. Laten we daar dan ook op focussen, en we horen het wel van TS als de opdracht omvangrijker is.

Wat aandachtspunten:

• Ik zie nergens een BTW codering. Een product wordt altijd verkocht met een BTW percentage, en dat kan verschillen per product(etenswaren = 6%) maar ook per verkoop (Een buitenlandse klant betaalt vaak 0% BTW, ook op 19 en 6% BTW artikelen). Een optie is om het BTW percentage van de verkoop rechtstreeks te registreren, maar netter zou zijn om een aparte tabel te hanteren met BTW 0, BTW Hoog en BTW Laag records, inclusief begin en einddatum. BTW Percentages willen nog wel eens wijzigen, maar een product blijft daarbij wel in de BTW Hoog categorie vallen.... je wijzigt dan enkel het geldende BTW tarief.
• Je hebt een aparte tabel voor logins, wat suggereert dat je meerdere logins per klant kan hebben? Is dat wel de bedoeling? Anders gewoon de login tabel samenvoegen met klant.
• Ik snap het verschil tussen winkel_id en shop_id niet zo. Het lijkt erop dat je producten wilt koppelen aan verschillende winkels, en dat doe je met een shop_id. Kan dat niet gewoon direct met het winkel_id?
• Als sommige producten door meerdere winkels verkocht worden, dan zal je bij je verkoop_regel niet alleen je product moeten registreren, maar ook de winkel waarbij deze gekocht is.
• Als producten maar exclusief door 1 winkel verkocht kunnen worden, dan kan je de koppeltabel tussen product en winkel weggooien

Succes

[Creepy]

De discussie over het waterval model is afgesplitst naar Waterval model nog bruikbaar in deze tijd?

[Verwijderd]

Wow. Bedankt voor jullie reacties, die helpen mij heel erg.
Om alle vragen te beantwoorden kost mij op dit moment teveel tijd.

Het is me wel duidelijk dat er een heleboel bij komt kijken, ik zal eerst nog eens met pen en papier de boel voor mezelf wat duidelijker schetsen.

De database was natuurlijk verre van klaar, daar ging mijn vraag ook een beetje over, waar ik allemaal nog meer op moet letten, dat is zo'n beetje wel duidelijk. Ik zal nog een beetje meer aan het knutselen gaan en kijken hoe er dan over gedacht word.

Hartelijk bedankt.

[Verwijderd]

Ik heb een nieuwe database gemaakt, omdat het alweer 10 dagen geleden is dat ik hier poste hoop ik dat een dubbelpost geen ramp is.



Wat denken jullie hiervan?

[Janoz]

Als ik even vlot kijk zie ik al een paar rare dingetjes :
- nummering in kolommen is altijd een slecht teken. Wat is de bedoeling met de tabel "afbeeldingen"?

- Op een aantal plekken wordt een 1:N relatie gebruikt terwijl het mij logischer lijkt wanneer daar een N:M relatie gebruikt wordt. Zo kan ik me voorstellen dat een gebruiker meer dan 1 rechten heeft en dat een winkel misschien wel meer dan 1 beheerder heeft. Tot slot lijkt het me ook niet onredelijk dat er meerdere winkels zouden kunnen zijn die hetzelfde product verkopen, maar zonder de functionele eisen te kennen kan ik niet zeggen of dat wel of niet klopt.

[Matis]

Janoz schreef op vrijdag 22 april 2011 @ 15:10:
Als ik even vlot kijk zie ik al een paar rare dingetjes :
- nummering in kolommen is altijd een slecht teken. Wat is de bedoeling met de tabel "afbeeldingen"?

Ik zal daar persoonlijk ook weer een koppeltabel voor maken. Zo kun je in de toekomst ook 7 8 of 9 afbeeldingen per ID kwijt.

Edit; waarin heb jij die grafische weergave van de ERD zo gekregen. Ik gebruik zelf MySQL Workbench, maar daarin kun je volgens mij geen grafische ERD krijgen. Al gevonden, zit standaard in Workbench, maar via een ander menu

[ Voor 23% gewijzigd door Matis op 22-04-2011 15:53 ]

[Janoz]

Matis schreef op vrijdag 22 april 2011 @ 15:13:
Ik zal daar persoonlijk ook weer een koppeltabel voor maken. Zo kun je in de toekomst ook 7 8 of 9 afbeeldingen per ID kwijt.

Niet te snel. Je doet hier allemaal aannames. Vandaar mijn vraag wat nu precies de bedoeling was. Gaat het om voorkomens van hetzelfde plaatje of zijn het juist verschillende plaatjes van hetzelfde product? En kan een categorie ook meerdere plaatjes hebben.

Zou het gaan om een enkel plaatje per categorie en meerdere plaatjes van een product dan zou ik niet eens met een koppeltabel gaan werken, maar juist de relatie omdraaien. Niet product een afbeeldingsID geven, maar een afbeelding een productId. Een categorieafbeelding zou ik misschien wel helemaal niet in een aparte tabel op nemen.

[Matis]

Janoz schreef op vrijdag 22 april 2011 @ 15:36:
***

Zoals ik al aangaf, persoonlijk neig ik al snel naar de 1:N relatieboom. Zonder enige vorm van kennis over het systeem.

Wanneer het dezelfde afbeeldingen zijn, maar alleen een ander formaat (thumbnail, small, large, full, raw) oid, dan is idd de naamgeving van dat tabel wat knullig.

[Standeman]

Matis schreef op vrijdag 22 april 2011 @ 15:13:
[...]

Edit; waarin heb jij die grafische weergave van de ERD zo gekregen. Ik gebruik zelf MySQL Workbench, maar daarin kun je volgens mij geen grafische ERD krijgen. Al gevonden, zit standaard in Workbench, maar via een ander menu :)[/s]

offtopic:
In ieder geval in versie 5.2 kan je bestaande db's reverse engineren of een nieuw model aanmaken.

[Janoz]

Matis schreef op vrijdag 22 april 2011 @ 15:49:
persoonlijk neig ik al snel naar de 1:N relatieboom.

Waarom stel je dan een koppeltabel voor? Die gebruik je namelijk bij een N:M

[Matis]

Janoz schreef op vrijdag 22 april 2011 @ 16:09:
Waarom stel je dan een koppeltabel voor? Die gebruik je namelijk bij een N:M

Ik doelde meer op de afbeelding 1 tm6, dat dat misschien netter in een 1:N relatie kan, wanneer de afbeeldingen an sich niets met elkaar te maken hebben.

Persoonlijk vind ik de veel:1 relatie tussen producten en afbeeldingen erg vreemd

[Verwijderd]

Janoz schreef op vrijdag 22 april 2011 @ 15:10:
Als ik even vlot kijk zie ik al een paar rare dingetjes :
- nummering in kolommen is altijd een slecht teken. Wat is de bedoeling met de tabel "afbeeldingen"?

- Op een aantal plekken wordt een 1:N relatie gebruikt terwijl het mij logischer lijkt wanneer daar een N:M relatie gebruikt wordt. Zo kan ik me voorstellen dat een gebruiker meer dan 1 rechten heeft en dat een winkel misschien wel meer dan 1 beheerder heeft. Tot slot lijkt het me ook niet onredelijk dat er meerdere winkels zouden kunnen zijn die hetzelfde product verkopen, maar zonder de functionele eisen te kennen kan ik niet zeggen of dat wel of niet klopt.

Om je tweede post en deze maar ff gelijk te beantwoorden. Het lijkt mij inderdaad beter als ik bij de tabel categorie gewoon 1 afbeelding kan neerzetten. Maar nu ben ik er nog niet overuit waarom ik dit ook niet bij producten kan doen, gewoon een maximum van 5 of 6 afbeeldingen, daar hoef ik toch niet perse een andere tabel voor te gebruiken? Hoe zouden jullie het doen?

Ook moet het inderdaad mogelijk zijn dat een winkel meerdere beheerders kan hebben, bijvoorbeeld dat de eigenaar alles kan doen en bekijken (de statestieken, de verkochte producten, nieuwe dingen toevoegen etc) en dat een werknemer alleen producten kan toevoegen.

edit:
Ik zal de relationships nog even goed doorkijken, daar heb ik nog niet goed genoeg naar gekeken


Maar iedereen heel erg bedankt voor het antwoorden, ik vind het maken van een database nog een moeilijk punt en probeer zoveel mogelijk er over te weten te komen

[ Voor 8% gewijzigd door Verwijderd op 22-04-2011 16:35 ]

[Janoz]

Verwijderd schreef op vrijdag 22 april 2011 @ 16:32:
Maar nu ben ik er nog niet overuit waarom ik dit ook niet bij producten kan doen, gewoon een maximum van of 6 afbeeldingen, daar hoef ik toch niet perse een andere tabel voor te gebruiken?

Als je meerdere afbeeldingen bij een product hebt dan betekend dat er een 1:N relatie tussen afbeelding en product is. De juiste oplossing daarvoor is het opnemen van een productId in de afbeeldingen tabel.

Bij je huidige oplossing heb je dat precies verkeerdom gedaan door een afbeeldingId in het product op te nemen. Hetzelfde afbeeldingen record kan nu bij meerdere producten horen. En om meer afbeeldingen bij een product te krijgen heb je vervolgens als kunstgreep meer kolommen aan het afbeeldingen record toegevoegd.


@Matis: Precies, een 1:N, niet een N:M en dus ook geen koppeltabel.

[ Voor 3% gewijzigd door Janoz op 22-04-2011 16:42 ]

[Verwijderd]

Janoz schreef op vrijdag 22 april 2011 @ 16:40:
[...]

Als je meerdere afbeeldingen bij een product hebt dan betekend dat er een 1:N relatie tussen afbeelding en product is. De juiste oplossing daarvoor is het opnemen van een productId in de afbeeldingen tabel.

Bij je huidige oplossing heb je dat precies verkeerdom gedaan door een afbeeldingId in het product op te nemen. Hetzelfde afbeeldingen record kan nu bij meerdere producten horen. En om meer afbeeldingen bij een product te krijgen heb je vervolgens als kunstgreep meer kolommen aan het afbeeldingen record toegevoegd.


@Matis: Precies, een 1:N, niet een N:M en dus ook geen koppeltabel.

Bedankt, daar kan ik wat mee.

Heeft iemand een idee hoe ik met permissie's voor verschillende gebruikers kan gaan werken. Ik kwam de term Role-Based Access Control (RBAC) tegen tijdens het googlen, maar ben er nog niet overuit hoe ik dat in deze database implementeer

[ Voor 0% gewijzigd door Verwijderd op 26-04-2011 14:39 . Reden: spelling ]

[Matis]

Volgens mij zijn er al een aantal topics betreffende dat topic de revue gepasseerd, maar ik kan ze zo snel niet vinden.

Ik meen me te kunnen herinneren dat ze veelal neerkwamen op een soort van featureset, waar je dus een aantal bits hebt (voorbeeld 16) waarin je per bit aangeeft wat je wel (of niet mag).
Zo kan bitje 0 aangeven dat je een nieuwe gebruiker mag toevoegen.
Bitje 1 is dat je een afbeelding mag toevoegen.
Dus iemand met rechtenset 0 kan dat niet, met 1 kan alleen nieuwe gebruiker toevoegen en 3 kan dus allebei.

Volgens mij hield het zoiets in.

[Grijze Vos]

Matis schreef op dinsdag 26 april 2011 @ 14:12:
Volgens mij zijn er al een aantal topics betreffende dat topic de revue gepasseerd, maar ik kan ze zo snel niet vinden.

Ik meen me te kunnen herinneren dat ze veelal neerkwamen op een soort van featureset, waar je dus een aantal bits hebt (voorbeeld 16) waarin je per bit aangeeft wat je wel (of niet mag).
Zo kan bitje 0 aangeven dat je een nieuwe gebruiker mag toevoegen.
Bitje 1 is dat je een afbeelding mag toevoegen.
Dus iemand met rechtenset 0 kan dat niet, met 1 kan alleen nieuwe gebruiker toevoegen en 3 kan dus allebei.

Volgens mij hield het zoiets in.

Dat is gewoon bitflags gebruiken, en heeft an sich niks met RBAC te maken.

Het concept van RBAC is dat je gebruikers onderbrengt in verschillende rollen. Je geeft dan rollen rechten, ipv gebruikers. Dit zorgt voor een stuk minder beheer omdat het aantal rollen een stuk kleiner is dan het aantal gebruikers.

[Woy]

Als je met bits gaat werken loop je al snel tegen beperkingen aan. Ten eerste moet je vooraf duidelijk definiëren welke bit voor welke rechten staan, en is het dus lastiger om het laten aan te passen, en ten tweede loop je snel tegen de limiet van het data-type waarin je het hebt opgeslagen op.

Wat je kunt overwegen is om Tokens te defineren ( Die je natuurlijk gewoon in een tabel op kunt slaan ), en Permissions op Tokens te geven aan de hand van welke User er is ingelogd en in welke Role hij zit.

Voor het schrijven van een BlogPost kun je dan bijvoorbeeld BLOGPOST_WRITE vereisen. Op die manier is het later makkelijk om extra rechten toe te voegen. Als het complexer word zou je daar ook niet iets van Resources aan toe kunnen voegen.

[Matis]

Woy schreef op dinsdag 26 april 2011 @ 14:43:
Als je met bits gaat werken loop je al snel tegen beperkingen aan. Ten eerste moet je vooraf duidelijk definiëren welke bit voor welke rechten staan, en is het dus lastiger om het laten aan te passen, en ten tweede loop je snel tegen de limiet van het data-type waarin je het hebt opgeslagen op.

Daar heb je gelijk in. Ik gaf ook alleen maar aan, wat mij bijstond van dergelijke topics.

Wat je kunt overwegen is om Tokens te defineren ( Die je natuurlijk gewoon in een tabel op kunt slaan ), en Permissions op Tokens te geven aan de hand van welke User er is ingelogd en in welke Role hij zit.

Voor het schrijven van een BlogPost kun je dan bijvoorbeeld BLOGPOST_WRITE vereisen. Op die manier is het later makkelijk om extra rechten toe te voegen. Als het complexer word zou je daar ook niet iets van Resources aan toe kunnen voegen.

Ben je in dat laatste geval niet bezig om een ACL op te zetten in plaats van een RBAC?

[ Voor 3% gewijzigd door Matis op 26-04-2011 14:48 ]

[Woy]

Matis schreef op dinsdag 26 april 2011 @ 14:47:
[...]
Ben je in dat laatste geval niet bezig om een ACL op te zetten in plaats van een RBAC?

In feite wel. Maar als je het wat versimpeld, en dus de Tokens weg-laat, en direct een Role vereist heb je een RBAC.

Je hebt dan feitelijk alleen een Users, Roles en UserRoles tabel nodig. In je code kan je dan gewoon een simpele user.IsInRole( "RoleName" ) check doen.

Het voordeel van het introduceren van Tokens is dat je later makkelijker de rechtenset van een Role kunt veranderen.

[ Voor 11% gewijzigd door Woy op 26-04-2011 14:55 ]

[Verwijderd]

Woy schreef op dinsdag 26 april 2011 @ 14:54:
Je hebt dan feitelijk alleen een Users, Roles en UserRoles tabel nodig. In je code kan je dan gewoon een simpele user.IsInRole( "RoleName" ) check doen.

Hoe bedoel je dit?

Ik heb een tabel Gebruikers (Users).
Ik maak een tabel Roles, wat stop ik daar in? De verschillende gebruikersgroepen (Admin, Winkel Eigenaar, Winkel Personeel etc)?
Zelfde vraag voor UserRoles, stop ik daar de verschillende rechten in die de gebruikers hebben (bijv het recht om je winkel omschrijving aan te passen, of producten toevoegen/aanpassen/verwijderen?)

[Woy]

In het simpelste geval

Users = Alle gebruikers die je hebt, met password hash/salt o.i.d. ( Al kun je de authenticatie natuurlijk ook door een ander systeem laten afhandelen )
Roles = Alle groepen/roles die je hebt
UserRoles = Koppeltabel tussen Users en Roles om aan te geven in welke Roles een user zit.

Voor elke actie die je uitvoert kun je dan een Rol vereisen, en voordat je die actie uitvoert check je dus of de huidige gebruiker in de benodigde rol zit.

Een Rol moet je eigenlijk niet zien als een recht, maar meer als een functie. Bij het afrekenen van een aankoop moet je bijvoorbeeld de rol Kassière hebben.

[ Voor 24% gewijzigd door Woy op 26-04-2011 15:25 ]

[Janoz]

Nee, niet helemaal. "het recht om je winkel omschrijving aan te passen" is iets wat je in je code regelt. Bij de 'updateOmschrijving()' methode controleer je of de gebruiker (bv) de rol 'WinkelBeheerder' heeft. Het enige dat je in de database opslaat is dat gebruiker X de rol WinkelBeheerder heeft. Dit is echter wel een N:M koppeling (vandaar de UserRole koppeltabel) omdat een gebruiker meerdere rollen kan hebben en een rol bij meerdere gebruikers kan horen.

[alienfruit]

Waar gebruik je de column type decimal voor de produktprijs? Dan is je duurste produkt dus 9999,99?

[xzaz]

Wat huishoudelijke vragen / opmerkingen:
- Is er een reden waarom je het in het Nederlands doet? Programmeer je ook in het Nederlands? Of hou je Nederlands aan als standaard omdat het moet van de klant?
- Wat is de reden van de prefixes in de tabellen? Zoals producten.producten_btw met de tabel geef je eigenlijk al aan dat de attribuut daarbij hoort. Zoals producten.btw.

[RuudvandeBeeten]

Wat is de reden dat je het datatype TINYINT gebruikt de kolom "product_zichtbaar" van de tabel "producten"? Ik neem aan dat je dit veld gebruikt om alleen de actieve/actuele/niet verwijderde producten te tonen. Hier zou je een BIT voor kunnen pakken.

Daarnaast zou ik het zelfde principe opnemen bij "categorie". Ik kan me voorstellen dat je een categorie ook kan verwijderen.

Iets wat eerder ook al genoemd was in dit topic is het gebruik van prefixen :, die zou ik weglaten. Wanneer je de naam van een product wilt weten vraag je toch al aan de tabel "product" -> "naam"?

Succes met je opdracht!

[ Voor 0% gewijzigd door RuudvandeBeeten op 05-05-2011 13:35 . Reden: Spelling ]

[Moraelyn]

Wat als ik als gebruiker aan de kerkstraat 1A woon? Hoe stop je dat in de DB?

Ik kan het in ieder geval daar laten bezorgen, want bij bestellingen is het "opeens" adres in plaats van straat en huisnummer. Is daar een specifieke reden voor? Idem voor telefoon. Bij winkel is dit int, bij gebruiker en bestelling een varchar.

Je zou kunnen overwegen om plaats, gemeente en provincie in aparte (koppel) tabellen te stoppen ivm gemeentelijke herindelingen en dergelijke. Hier kun je bijvoorbeeld zo'n lijst downloaden die regelmatig bijgewerkt schijnt te worden. In hoeverre je dat moet normaliseren moet je zelf weten, maar wanneer je een standaardlijstje ergens vandaan kunt halen, dat in een tabel stopt en daar op gaat koppelen in je DB waardoor je voorkomt dat je zelf (of bepaalde gebruikers) handmatig wijzigingen moet bijhouden en doorvoeren dan scheelt dat natuurlijk een heleboel tijd.

[Verwijderd]

RuudvandeBeeten schreef op donderdag 05 mei 2011 @ 13:34:
Wat is de reden dat je het datatype TINYINT gebruikt de kolom "product_zichtbaar" van de tabel "producten"? Ik neem aan dat je dit veld gebruikt om alleen de actieve/actuele/niet verwijderde producten te tonen. Hier zou je een BIT voor kunnen pakken.

Een 'BOOLEAN' in MySQL in een synoniem voor 'TINYINT(1)', dat is dus wel 't datatype wat daar gebruikelijk voor is.

[RuudvandeBeeten]

Verwijderd schreef op donderdag 05 mei 2011 @ 19:11:
[...]

Een 'BOOLEAN' in MySQL in een synoniem voor 'TINYINT(1)', dat is dus wel 't datatype wat daar gebruikelijk voor is.

Bedankt voor de verduidelijking. Ik heb zelf geen ervaring met MySQL dus vandaar de vraag.

Ik heb gezocht naar het gebruik van boolean's in MySQL en vond een goed antwoord hier: phttp://stackoverflow.com/...oolean-values-from-to-php.