Advies over database design

Wat zijn "gebruikers": zijn dat de behandelaars of de behandelden?

Met andere woorden, er ontbreken één of twee categorieën personen: wie behandelt wie en wie maakt een afspraak met wie voor wie?

Verder zou ik een geschatte behandelduur opnemen per behandeling. Dit voorkomt dat je dubbele (overlappende) afspraken inplant en zorgt ervoor dat je omgekeerd kunt zien waar je nog een "gaatje" vrij hebt in de planning.

Een ontwerp van een kapsalon om te beginnen.

https://holowczak.com/the-hair-salon-database-project/

Ward van der Put op 28/12/2020 16:30:52

Wat zijn "gebruikers": zijn dat de behandelaars of de behandelden?

Met andere woorden, er ontbreken één of twee categorieën personen: wie behandelt wie en wie maakt een afspraak met wie voor wie?

Verder zou ik een geschatte behandelduur opnemen per behandeling. Dit voorkomt dat je dubbele (overlappende) afspraken inplant en zorgt ervoor dat je omgekeerd kunt zien waar je nog een "gaatje" vrij hebt in de planning.

Bedankt voor je reactie.
Ik heb nogmaals naar mijn DB-design en ik heb het her en der wat aangepast om het compleet te maken.
Onderstaande is de nieuwe versie.
Ik begrijp niet helemaal met wat je bedoelt over behandelduur? Want dit systeem is echt bedoeld om inzicht te geven en zij gaan het niet gebruiken tbv het plannen.
Als er vragen zijn, dan hoor ik dat graag.


Tabelstructuur voor tabel Behandelaars
Kolom Type Leeg Standaardwaarde
BehandelaarID int(11) Nee
Voornaam varchar(20) Nee
Achternaam varchar(40) Nee
Bedrijfsnaam varchar(255) Nee
Mailadres varchar(255) Nee
Wachtwoord varchar(255) Nee
Functie varchar(255) Nee
Activatie varchar(255) Ja NULL
DatumActief Datetime Nee
DomeinActief tinyint(1) Ja NULL
GebruikerLevel tinyint(1) Nee
DatumAanmaak Datetime Nee
Gegevens worden geëxporteerd voor tabel Behandelaars

Tabelstructuur voor tabel Behandelingen
Kolom Type Leeg Standaardwaarde
BehandelingID int(11) Nee
BehandelingNaam varchar(255) Nee
BehandelingPrijs decimal(10,2) Nee
DatumAanmaak datetime Nee
BehandelaarID int(11) Nee
Gegevens worden geëxporteerd voor tabel Behandelingen

Tabelstructuur voor tabel Klanten
Kolom Type Leeg Standaardwaarde
KlantID int(11) Nee
Voornaam varchar(255) Nee
Achternaam varchar(255) Nee
Telefoonnummer varchar(255) Nee
DatumAanmaak Datetime Nee
Gegevens worden geëxporteerd voor tabel Klanten

Tabelstructuur voor tabel orders
Kolom Type Leeg Standaardwaarde
OrderID int(11) Nee
OrderDate datetime Nee
KlantID int(11) Nee
BehandelingID int(11) Nee



[size=xsmall]Toevoeging op 28/12/2020 23:56:11:[/size]

Adoptive Solution op 28/12/2020 17:42:59

Een ontwerp van een kapsalon om te beginnen.

https://holowczak.com/the-hair-salon-database-project/

Bedankt voor je reactie. Ik heb even naar gekeken en het ziet er zeker goed uit, maar ik hou het liever bij mijn eigen design, zodat ik het beter begrip. Mocht ik later wat willen aanpassen dan ben ik niet afhankelijk van hen.

Leuk idee, om een eigen database-ontwerp hiervoor te maken en het in eigen hand te willen houden.

Mijn eerste vraag is: waarom heb je niet voor PostgreSQL gekozen? Daarmee hoef je minder bezig te zijn met technisch geneuzel, en heb je meer database voor je geld (en tijd).

Mocht je MySQL blijven gebruiken, dan heb ik de volgende suggesties:

1.) gebruik alleen onderkast voor identifiers als tabel- en kolomnamen, dan hoef je niet alles te escapen met backticks

2.) gebruik alleen TEXT, geen VARCHAR.
Wil je echt de lengte van namen beperken zoals de achternaam, maak dan een CHECK op de kolommen en zorg voor voldoente ruimte (bv.: https://nl.wikipedia.org/wiki/Lijst_van_langste_achternamen_van_Nederland)

3.) gebruik UNSIGNED INTs voor primaire sleutels, AUTO_INCREMENT waarden zijn niet negatief.

4.) vermijd NULLs tenzij ze echt nodig zijn

5.) wees je bewust van DATETIME: deze slaat geen tijdzone-informatie op waardoor het afhankelijk is van de instelling van de MySQL-server.
Hierover zijn verschillende artikelen, bv. https://javorszky.co.uk/2016/06/06/today-i-learned-about-mysql-and-timezones/

6.) gebruik alleen de InnoDB storage engine in MySQL en maak gebruik van FOREIGN KEY CONSTRAINTS.

7.) let op met standaardwaarden bij een ON UPDATE. Als je ooit met een clientprogramma iets recht moet trekken kan je data onbedoeld corrupt raken.

8.) probeer ook zoveel mogelijk input validatie aan de database-kant te doen, met de nodige CHECKs.
Zie: https://dev.mysql.com/doc/refman/8.0/en/create-table-check-constraints.html

9.) Je lijkt het wachtwoord op te slaan in plain text. Dat moet je nooit doen.
Zie voor meer info: https://owasp.org/www-community/vulnerabilities/Password_Plaintext_Storage
Het meestvoorkomende scenario is dat je in PHP het wachtwoord aanmaakt en valideert met password_hash() en password_verify(). Je slaat dan alleen de hash op in bij `Wachtwoord`. Een hash is zonder encoding, je kunt er beter een BLOB van maken.

Volgens mij biedt mijn hostingbedrijf geen PostgreSQL aan en daarom gebruik ik MySql..
Maakt het uit of ik Mysql of PostgreSQL gebruik?
Ergens heb ik gelezen dat je standaard PostreSQL gebruikt wanneer je de nieuwste XAMP server gebruikt, maar de lay-out is nog die van MySql.
Sorry, maar ik weet niet wat je bedoelt met het eerste punt?
In elke tutorial wordt gezegd dat je beter varchar kunt gebruiken tov char, want afhankelijk van de inhoud, wordt alleen zoveel bytes opgeslagen en niet standaard bytes. Hierdoor wordt je DB ook niet extra groot...
Het wachtwoord ga ik sowieso coderen en dan pas opslaan en NOOIT in plaintext.

Wat vond je verder van het design?
Over de tabel behandeling zijn er een paar behandeling die zowel voor de mannen als voor de vrouwen gelden, allen zijn de prijzen anders.
Enig idee hoe ik dit kan opnemen in mijn DB-design?

Ik verwees naar een voorbeeld database ontwerp dat je kan gebruiken als inspiratie.

Maar je hechtte meer waarde aan je eigen ontwerp.

Nu vraag je iets wat in dat ontwerp voorkomt.

Hier, bij het invoeren van de data :
https://holowczak.com/the-hair-salon-database-project/5/?amp=1

Dit bijvoorbeeld :

INSERT INTO SalonService VALUES ('SV101', 'Men''s Haircut', 20, 22, 'None');
INSERT INTO SalonService VALUES ('SV102', 'Women''s Haircut', 30, 32, 'None');

Volgens mij heb ik nu versie 2 gemaakt van mijn DB-design en toen ik erover ging nadenken, kwam ik weer dingen tegen waar ik niet aan had gedacht.
Ik heb eerder snel gekeken naar die link die je stuurde, maar lette niet op details.

Het probleem waar ik tegen aanloop is dat in mijn DB-design moet opnemen dat dezelfde behandeling verschillende prijzen heeft obv geslacht. Dus haarknippen voor vrouwen is duurder dan voor mannen. Vraag mij niet waarom, maar misschien hebben vrouwen meer te besteden tegenwoordig!

Ik heb dus even verder gezocht en ik kwam deze URL tegen:
https://stackoverflow.com/questions/23297259/database-design-for-products-with-multiple-prices
Het is precies hetzelfde probleem, maar de aangedragen oplossing begrijp ik niet helemaal, zoals de oplossing in jouw link.
Die link die je stuurde zie ik wel een SalonService tabel, maar de opgenomen attributen begrijp ik niet en ik zie geen link naar de oplossing.
Misschien dat je het eea wil uitleggen...

Mohamed nvt op 30/12/2020 00:24:09

Dus haarknippen voor vrouwen is duurder dan voor mannen. Vraag mij niet waarom, maar misschien hebben vrouwen meer te besteden tegenwoordig!

Of ze hebben over het algemeen meer haar dan mannen en ingewikkeldere kapsels ;)

Ozzie PHP op 30/12/2020 01:05:03

[quote="Mohamed nvt op 30/12/2020 00:24:09"]
Dus haarknippen voor vrouwen is duurder dan voor mannen. Vraag mij niet waarom, maar misschien hebben vrouwen meer te besteden tegenwoordig!

Of ze hebben over het algemeen meer haar dan mannen en ingewikkeldere kapsels ;)


[/quote]
Haha! Dat sowieso, maar ze gaan ook vaker naar de kapper en dus is de vraag ernaar ook groter en daarom misschien ook duurder ;-)

Of mannen of vrouwen geknipt worden zou ik in ieder geval zeker niet koppelen aan de klant.
Maak er gewoon een apart product van: Knippen heren, knippen vrouwen.

Voor hetzelfde geldt betaalt de man zelf de knipbeurt voor de vrouw.