Advies over database design
Een goede vriend van mij heeft een kapsalon en heeft mij gevraagd of ik voor hem een simpele webapplicatie kan maken voor het maken/beheren van de knipafspraken tbv zijn klanten.
Hieronder wat uitleg over het DB-design:
In totaal heb ik 3 tabellen gemaakt.
Omdat er een many-to-many relatie bestaat tussen gebruikers en behandelingen heb ik hiervoor een aparte tabel gemaakt met orders zodat er one-to-many relatie bestaat.
Ik ben benieuwd naar wat jullie van het design vinden en/of jullie nog opmerkingen/aanmerkingen hebben.
Tabelstructuur voor tabel Gebruikers
Kolom Type Leeg Standaardwaarde
GebruikerID 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
Tabelstructuur voor tabel Behandelingen
Kolom Type Leeg Standaardwaarde
BehandelingID int(11) Nee
BehandelingNaam varchar(255) Nee
BehandelingPrijs decimal(10,2) Nee
Tabelstructuur voor tabel Orders
Kolom Type Leeg Standaardwaarde
OrderID int(11) Nee
GebruikerID int(11) Nee
BehandelingID int(11) Nee
DatumUitvoering datetime Nee
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.
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.
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
Toevoeging op 28/12/2020 23:56:11:
Adoptive Solution op 28/12/2020 17:42:59:
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.
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.
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?
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 :
Code (php)
1
2
2
INSERT INTO SalonService VALUES ('SV101', 'Men''s Haircut', 20, 22, 'None');
INSERT INTO SalonService VALUES ('SV102', 'Women''s Haircut', 30, 32, 'None');
INSERT INTO SalonService VALUES ('SV102', 'Women''s Haircut', 30, 32, 'None');
Gewijzigd op 29/12/2020 22:22:34 door Adoptive Solution
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:
Of ze hebben over het algemeen meer haar dan mannen en ingewikkeldere kapsels ;)
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 ;)
Haha! Dat sowieso, maar ze gaan ook vaker naar de kapper en dus is de vraag ernaar ook groter en daarom misschien ook duurder ;-)
Maak er gewoon een apart product van: Knippen heren, knippen vrouwen.
Voor hetzelfde geldt betaalt de man zelf de knipbeurt voor de vrouw.
Hoofdlettergevoeligheid is gedoe, zoals wel meer dingen in MySQL..
Zie: https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html
Als je echt onderscheid wilt kunnen maken tussen een identifier als datumactief en DatumActief, moet je die laatste tussen backticks schrijven, zoals dit: `DatumActief`. Maar je kunt ook kiezen voor namen met kleine letters en een underscore, zoals dit: datum_actief. Die hoef je nooit tussen backticks te zetten. Hoewel je het kunt opvatten als een kwestie van smaak, raad ik het toch aan omdat het gedoe kan voorkomen.
Ik raad je aan om TEXT te gebruiken in plaats van VARCHAR en al helemaal boven CHAR.
Stel dat je zou zeggen dat kolom `Voornaam` van het type CHAR(20) is. Een kortere voornaam als Jan wordt opgeslagen als 'Jan ' (met 17 extra spaties). Je gooit dus ruimte weg. De enige reden om voor CHAR te kiezen is als de rijgrootte van een kolom een vaste lengte moet hebben voor het sneller kunnen opzoeken van data. Maar dat is hier niet van toepassing.
Zie: https://dev.mysql.com/doc/refman/8.0/en/char.html
VARCHAR is gedoe in MySQL. Neem bijvoorbeeld VARCHAR(255). Het slaat nergens meer op, maar het wordt veel gebruikt als voorbeeld. De 255 is niet (zoals je zou verwachten) het maximum aantal karakters, maar het maximum aantal bytes (in C "char"). Tegenwoordig gebruiken veel mensen UTF-8 (utf8mb4), maar dan kan een niet US-ASCII-karakter tot 6 bytes ruimte innemen. En alsof dat al niet ingewikkeld genoeg is om rekening mee te houden, heeft MySQL bedacht dat elke rij - zelfs met InnoDB - maximaal 65535 (64k - 1) bytes kan bevatten. Als je dus een bredere tabel hebt, met een paar kolommen met VARCHAR(32767), dan gaat MySQL tegensputteren.
Zie: https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html
De meest eenvoudige oplossing is om TEXT als kolomtype te gebruiken. Dan hoef je niet na te denken over extra bytes voor UTF-8, en je kunt eventueel eenvoudig opschalen naar MEDIUMTEXT of LONGTEXT. Als je dat zou willen kan je nog steeds een limiet op het aantal bytes zetten met een CHECK CONSTRAINT als LENGTH(`Voornaam`) <= 20. En de data van een kolom met het TEXT-datatype telt niet mee in de rijlimiet.
Simpeler kan MySQL het helaas niet maken, het is meer gedoe dan PostgreSQL. In PostgreSQL heb je geen limiet op rijen, in PostgreSQL maakt het niet uit of je VARCHAR of TEXT gebruikt, in PostgreSQL zijn aantallen in karakters in plaats van in bytes. In PostgreSQL ligt de focus op data, niet op technisch geneuzel. Vandaar mijn aanbeveling.
Als de prijzen afhangen van geslacht, dan heb je hiervoor een aparte kolom nodig in de prijstabel.
Maak niet de fout om ooit het datatype ENUM te gebruiken. In het geval van jouw kapper; er zijn ook LHBTI-mensen, of mensen waarvan het geslacht onbekend is, of die het überhaupt niet geregistreerd willen hebben. En dan komt de kapper weer bij jouw voor extra opties in de kolom geslacht. Gewoon altijd ENUM vermijden, dat werkt het beste.
Het meest puur is om een tabel geslacht aan te maken met een eigen id. Kan je die meteen extra kolommen geven als code en aanhef.
Vanuit de prijstabel maak je een kolom geslacht, met een FOREIGN KEY CONSTRAINT naar de tabel geslacht. In dezelfde prijstabel heb je ook een kolom nodig met een kolom product, met een FOREIGN KEY CONSTRAINT naar de producttabel.
Op de twee kolommen product en geslacht maak je een PRIMARY KEY constraint, je gebruikt hier geen AUTO_INCREMENT.
Je kunt eventueel de dubbele sleutel achterwege laten, en een extra id kolom maken waar wel een AUTO_INCREMENT op zit. Daarmee verschuift verantwoordelijkheid om data-integriteit te bewaken van de MySQL naar PHP. Sommige raamwerken kunnen slecht met dubbele sleutels overweg, dit kan een reden zijn om toch voor die id kolom te kiezen. Mijn aanbeveling is om alle data-gerelateerde taken zoveel mogelijk bij de database te beleggen, dus om wel te werken met een dubbele sleutel.
- Ariën - op 30/12/2020 13:54:14:
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.
Maak er gewoon een apart product van: Knippen heren, knippen vrouwen.
Voor hetzelfde geldt betaalt de man zelf de knipbeurt voor de vrouw.
Ik denk dat je daar een punt hebt. Ik ga denk ik twee aparte tabellen maken, gezien het twee aparte behandelingen zijn, dus eentje voor mannen en andere voor vrouwen met elk andere behandelingen erin.
Is het zo praktisch vraag ik mij af om twee aparte tabellen aan te maken, want ik wil dat juiste keuzemenu dus "behandelingen voor een man of een vrouw worden geladen vanuit DB" wanneer het geslacht wordt gekozen?
Nee, dat is niet bepaald netjes genormaliseerd. Je product (is overigens geen order) moet gewoon vertellen wat het is. Eventueel een veld of het een product is voor mannen, of voor vrouwen, of 'niet van toepassing' als je er nog wilt filteren.
Knippen heren - 15 euro - heren
Knippen vrouwen - 25 euro - vrouwen
Watergolven - 20 euro - vrouwen
Tondeuse heren - 10 euro - heren
Haarkleuren - 50 euro - niet van toepassing
Fles Hairlotion 0,33 l - 15 euro - niet van toepassing
Fantastic HairGel - 2,50 euro - niet van toepassing
Dat kan dus prima in een tabel.
En waarom ik in de records de geslachten in de titels plaats is heel simpel: Ook op het bonnetje wil je aan de klant laten zien welk product er gekozen is. Dan weet Annie bijvoorbeeld dat er gewoon 'Knippen vrouwen' is aangeslagen, wat meer vertrouwen geeft dan enkel 'Knippen' wat ook voor heren zou gelden.
Je kan ook de gelachts-velden bij de omschrijving betrekken, maar ik denk dat je het dan nodeloos complex maakt als je statistieken wilt uitdraaien. Feitelijk is er een groot verschil tussen knippen van dames en heren ;-)
Gewijzigd op 30/12/2020 23:20:38 door - Ariën -
Mohamed nvt op 30/12/2020 22:58:54:
Ik denk dat je daar een punt hebt. Ik ga denk ik twee aparte tabellen maken, gezien het twee aparte behandelingen zijn, dus eentje voor mannen en andere voor vrouwen met elk andere behandelingen erin.
Is het zo praktisch vraag ik mij af [..]
Is het zo praktisch vraag ik mij af [..]
Ik heb een hele verhandeling uitgetypt, misschien heb je daar iets aan?
- Ariën - op 30/12/2020 23:07:55:
Twee tabellen, dus een voor mannen, en een voor vrouwen?
Nee, dat is niet bepaald netjes genormaliseerd. Je product (is overigens geen order) moet gewoon vertellen wat het is. Eventueel een veld of het een product is voor mannen, of voor vrouwen, of 'niet van toepassing' als je er nog wilt filteren.
Knippen heren - 15 euro - heren
Knippen vrouwen - 25 euro - vrouwen
Watergolven - 20 euro - vrouwen
Tondeuse heren - 10 euro - heren
Haarkleuren - 50 euro - niet van toepassing
Fles Hairlotion 0,33 l - 15 euro - niet van toepassing
Fantastic HairGel - 2,50 euro - niet van toepassing
Dat kan dus prima in een tabel.
En waarom ik in de records de geslachten in de titels plaats is heel simpel: Ook op het bonnetje wil je aan de klant laten zien welk product er gekozen is. Dan weet Annie bijvoorbeeld dat er gewoon 'Knippen vrouwen' is aangeslagen, wat meer vertrouwen geeft dan enkel 'Knippen' wat ook voor heren zou gelden.
Je kan ook de gelachts-velden bij de omschrijving betrekken, maar ik denk dat je het dan nodeloos complex maakt als je statistieken wilt uitdraaien. Feitelijk is er een groot verschil tussen knippen van dames en heren ;-)
Nee, dat is niet bepaald netjes genormaliseerd. Je product (is overigens geen order) moet gewoon vertellen wat het is. Eventueel een veld of het een product is voor mannen, of voor vrouwen, of 'niet van toepassing' als je er nog wilt filteren.
Knippen heren - 15 euro - heren
Knippen vrouwen - 25 euro - vrouwen
Watergolven - 20 euro - vrouwen
Tondeuse heren - 10 euro - heren
Haarkleuren - 50 euro - niet van toepassing
Fles Hairlotion 0,33 l - 15 euro - niet van toepassing
Fantastic HairGel - 2,50 euro - niet van toepassing
Dat kan dus prima in een tabel.
En waarom ik in de records de geslachten in de titels plaats is heel simpel: Ook op het bonnetje wil je aan de klant laten zien welk product er gekozen is. Dan weet Annie bijvoorbeeld dat er gewoon 'Knippen vrouwen' is aangeslagen, wat meer vertrouwen geeft dan enkel 'Knippen' wat ook voor heren zou gelden.
Je kan ook de gelachts-velden bij de omschrijving betrekken, maar ik denk dat je het dan nodeloos complex maakt als je statistieken wilt uitdraaien. Feitelijk is er een groot verschil tussen knippen van dames en heren ;-)
Ik heb hier nogmaals naar gekeken en opzich vind ik het logisch om de behandeling, dus knippen voor mannen en vrouwen in een apart veld te benoemen. Dat is dan overzichtelijk wanneer de afspraak ingepland wordt.
Alleen de presentatie van deze behandelingen dmv dynamische dropdown-menu te laten zien, is dan niet compleet.
Want tegelijkertijd kan er één behandeling geselecteerd wordt en dat is volgens mij niet compleet. Want misschien wil een klant behalve knippen ook zijn baard doen, haren wassen...
Ik vraag mij af hoe ik dit kan doen als de dynamische dropdown-menu hiervoor niet geschikt is.
Ik heb een nieuwe DB-design gemaakt
https://www.w3schools.com/tags/att_select_multiple.asp
Ben benieuwd hoe zo’n dropdown menu eruit ziet in een ziekenhuis met 165 paginas behandelingen.
https://www.erasmusmc.nl/-/media/ErasmusMC/PDF/2-Themaoverstijgend/Passantenprijslijsten/Passantenprijslijst_2020.pdf?la=nl-NL
Toevoeging op 31/12/2020 15:39:23:
Je kan een dropdown menu ook vullen met typen :
https://www.w3schools.com/howto/howto_js_autocomplete.asp
Gewijzigd op 31/12/2020 15:32:43 door Adoptive Solution
Adoptive Solution op 31/12/2020 15:31:49:
Je kan een dropdown menu ook vullen met typen :
https://www.w3schools.com/howto/howto_js_autocomplete.asp
https://www.w3schools.com/howto/howto_js_autocomplete.asp
Dat kan tegenwoordig "een tikje eenvoudiger" met een datalist
Adoptive Solution op 31/12/2020 15:31:49:
Kijk eens :
https://www.w3schools.com/tags/att_select_multiple.asp
Ben benieuwd hoe zo’n dropdown menu eruit ziet in een ziekenhuis met 165 paginas behandelingen.
https://www.erasmusmc.nl/-/media/ErasmusMC/PDF/2-Themaoverstijgend/Passantenprijslijsten/Passantenprijslijst_2020.pdf?la=nl-NL
Toevoeging op 31/12/2020 15:39:23:
Je kan een dropdown menu ook vullen met typen :
https://www.w3schools.com/howto/howto_js_autocomplete.asp
https://www.w3schools.com/tags/att_select_multiple.asp
Ben benieuwd hoe zo’n dropdown menu eruit ziet in een ziekenhuis met 165 paginas behandelingen.
https://www.erasmusmc.nl/-/media/ErasmusMC/PDF/2-Themaoverstijgend/Passantenprijslijsten/Passantenprijslijst_2020.pdf?la=nl-NL
Toevoeging op 31/12/2020 15:39:23:
Je kan een dropdown menu ook vullen met typen :
https://www.w3schools.com/howto/howto_js_autocomplete.asp
Bedankt voor je suggesties en dit zijn hele goeie hoor.
Als ik dan kijk naar het gebruikersvriendelijkheid aspect kan ik denk ik beter kiezen voor een checkbox optie ipv dat een gebruiker dmv Ctrl meerdere behandelingen kan kiezen.
Met een checkbox heb ik het volgende bedacht:
Vanuit het DB laad ik alle behandeling in een kolom of een eigen div en links ervan is er een checkbox zodat een behandelaar kan een betreffende behandeling kiezen. Volgens mij is dit nog gebruikersvriendelijk.
Als ik dan een stapje verder denk, denk ik dat het zou handiger zou zijn om het nog eenvoudiger te maken door enerzijds gebruiker te maken van categorieën. Hiermee bedoel ik dat wanneer een behandelaar kiest voor alle behandelingen voor mannen, dat alleen die voor mannen worden weergegeven en hetzelfde geldt voor vrouwen.
Een andere optie is wanneer de behandeling linken aan het geslacht.
Hiermee bedoel ik dat tijdens het boeken van een afspraak dat wanneer het geslacht wordt gekozen dat alleen behandelingen voor betreffend geslacht worden weergegeven.
Ik ben er nog niet over uit...
vwb behandelingen in een ziekenhuis is er uiteraard meer keuzes, maar die zullen waarschijnlijk hebben gecategoriseerd om het enigszins overzichtelijk te maken.
Ik denk dat een datalist geen optie voor mij is, maar ik zal er nog verder naar kijken.
Toevoeging op 01/01/2021 14:57:23:
Rob Doemaarwat op 31/12/2020 16:56:41:
Dat kan tegenwoordig "een tikje eenvoudiger" met een datalist
Adoptive Solution op 31/12/2020 15:31:49:
Je kan een dropdown menu ook vullen met typen :
https://www.w3schools.com/howto/howto_js_autocomplete.asp
https://www.w3schools.com/howto/howto_js_autocomplete.asp
Dat kan tegenwoordig "een tikje eenvoudiger" met een datalist
Het autocomplete optie is zeker handig wanneer het recond al bestaat. Dus stel je voor dat een afspraak wordt gemaakt voor Pietje en dan hoe je niet telkens zijn naam in te vullen, maar dat je het kan selecteren na het invullen van een paar letters...
Toevoeging op 01/01/2021 14:58:57:
Ad Fundum op 31/12/2020 13:55:52:
Ik heb een hele verhandeling uitgetypt, misschien heb je daar iets aan?
Mohamed nvt op 30/12/2020 22:58:54:
Ik denk dat je daar een punt hebt. Ik ga denk ik twee aparte tabellen maken, gezien het twee aparte behandelingen zijn, dus eentje voor mannen en andere voor vrouwen met elk andere behandelingen erin.
Is het zo praktisch vraag ik mij af [..]
Is het zo praktisch vraag ik mij af [..]
Ik heb een hele verhandeling uitgetypt, misschien heb je daar iets aan?
Nogmaals dank voor je reactie.
Ik ga nog een keer naar kijken en erover nadenken. Het eea hangt af van gebruikersvriendelijkheid..
Mohamed nvt op 01/01/2021 14:54:26:
Het autocomplete optie is zeker handig wanneer het recond al bestaat. Dus stel je voor dat een afspraak wordt gemaakt voor Pietje en dan hoe je niet telkens zijn naam in te vullen, maar dat je het kan selecteren na het invullen van een paar letters...
Lekker makkelijk een autocomplete kunnen vullen met namen is geen grondslag met een gerechtvaardigd belang (PDF) voor het verwerken van persoonsgegevens conform de AVG/GDPR.
Meer praktisch lijkt het me ook omslachtig, tijdrovend, foutgevoelig en niet klantvriendelijk als bij de kassa of aan de balie steeds om persoonsgegevens en toestemming voor het verwerken van die persoonsgegevens moet vragen.
In mijn programma maak ik gebruik van dergelijke constructie, om mensen die zich vaker dan eens hebben aangemeld te herkennen. Dat herkennen is in mijn specifieke geval een gerechtvaardigd belang.
Maar je komt niet zomaar weg met een datalist vullen, er hoort vanalles bij: je moet mensen inderdaad om toestemming vragen, of ze op voorhand duidelijk maken dat hun gegevens worden bewaard en wat de rechten zijn (in termen van Nederlands recht), zoals recht van inzage. Maar je moet ook een redelijke bewaartermijn hanteren. En de opslag van gegevens moet voldoen aan veiligheidseisen zoals van NEN-IEC/ISO 27001 en 27002 en OWASP.
En dat alles moet overeind kunnen blijven staan wanneer een jurist er naar kijkt.