Graag zou ik willen weten of ik in de juiste richting zit te denken.
Vanuit mijn database maak ik opties aan voor in de select, zodat gebruikers alleen daar de keus uit hebben.
Natuurlijk wil je niet dat via de inspector de waardes alsnog kunnen worden aangepast.
Ik wil dus een controle of de waarde ook overeenkomt met de lijst uit de database.
Is het dan verstandig als het formulier geladen word eerst de waardes in een array te zetten en met een foreach loop de opties aan te maken en de controle te doen met array_key_exists?
>> Met gegevensvalidatie bedoel ik de juistheid van de gegevens. Of een foreign key geldig is, of een string niet te lang is en aan een bepaalde vorm voldoet, of een datum binnen een bepaalde termijn valt. Dat soort dingen.
Oké, dus allemaal dingen die je inderdaad ook via PHP kunt regelen.
>> Dat tegenargument had ik ook verzonnen, maar het gaat niet op. Want dat zou dan ook moeten gelden voor PHP, en het besturingssysteem.
Dat hangt er vanaf wat je 'leading' maakt. Als je een website bouwt met behulp van PHP dan is PHP leading. PHP is als het ware de piloot en bepaalt wat er gebeurt. Jij hebt nog een tweede piloot die altijd nodig is om je applicatie in de lucht te houden ... je database. Als je database niet meer werkt, stort je neer.
Ja, natuurlijk treden er wel eens wijzigingen op in PHP. Je piloot zul je dan even op een paar punten moeten bijscholen. Maar alleen die ene piloot en niet een tweede piloot.
Uiteraard is dit alles discutabel en als jij liever bepaalde controles en verantwoordelijkheden overlaat aan je database is dat prima. Je kunt alleen niet stellen dat dat "de beste" manier is. Het is een andere manier en beide manieren hebben voor- en nadelen.
Een controle of er al een tijd bezet is niet nodig.
In de database staat een begin en eindtijd die ik met intervallen van een kwartier laad zien.
Ik wil enkel de controle of het binnen de start en eindtijd valt en of het inderdaad om een interval van een kwartier gaat.
Is het dan niet het handigste om met een loop een array te bouwen en hierin te controleren?
Het ging er toch om of iemand de tijdsduur niet had gemanipuleerd?
Zoals ik eerder al heb aangegeven kun je een aan een tijdvak een value koppelen.
"Aan zo'n tijd of tijdvak kun je een value koppelen, bijv. 202009111315 voor het tijdstip 13.15 uur op 11 september 2020. Of in het geval van een tijdvak 2020091113151330."
De value 2020091113151330 staat dan voor
2020 jaar
09 maand
11 dag
1315 begintijd
1330 eindtijd
Je kunt dus controleren of deze string 2020091113151330 geldig is.
Bijvoorbeeld als volg (dit is enkel een voorbeeld):
- De eerste 4 cijfers moet een getal zijn dat ligt tussen het huidige jaartal en het huidige jaartal + 2
- de 2 volgende cijfers liggen tussen 01 en 012 (maand)
- de 2 volgende cijfers liggen tussen 01 en 31 (dag)
- de 4 volgende cijfers moeten eindigen op 00, 15, 30 of 45 (begintijd)
- de 4 volgende cijfers minus de 4 vorige cijfers is gelijk aan 15 (eindtijd-begintijd=15 minuten)
Als je zo'n soort controle uitvoert, dan weet je of er wel of niet geknoeid is met de gegevens.
Stel je zou een value van 2020091113171330 terugkrijgen dan zou uit je controle blijken dat de begintijd eindigt op 17 en dat klopt niet. Dan breek je de operatie dus af.
Thomas ziet een database als simpele/domme opslagbron waar je data in stopt en weer uithaalt.
Dit heb ik nergens beweerd, en dat is ook helemaal niet wat ik bedoelde. Ik plaatste alleen de kanttekening dat de verantwoordelijkheid niet 100% in de database zélf hoeft te liggen.
Ozzie PHP op 16/09/2020 11:27:01
In theorie zou je in een op OOP gebaseerde applicatie binnen 5 minuten van type database moeten kunnen wisselen, simpelweg door de huidige database class te vervangen door een nieuwe database class die communiceert met de nieuwe database. (Dit is de theorie. In de praktijk zul je misschien her en der nog wat queries moeten aanpassen.)
Dit is echt de grootste flauwekul die er is, als we het hier over PDO hebben. Dit valse argument wordt al jaren (verkeerd) gebruikt om PDO te verkiezen boven mysqli ("het ondersteunt meerdere databases").
In eerste instantie omdat je dit normaliter nooit doet. Je ontwerpt een applicatie niet om vervolgens de optie open te houden om het in meerdere typen databases op te slaan. Tenzij je aan het testen bent of dit in het gebruik sneller/beter werkt, en dan kies je vervolgens uiteindelijk toch voor één database.
Dit is zoiets als:
Ik wil graag een auto
- Deze heeft twintig wielen meneer
Maar ik heb geen twintig wielen nodig, ik heb er maar vier nodig, een simpele auto doet al alles wat ik wil
- Maar deze heeft er twintig, en dat zijn er méér en dus is het béter
Wat?
- Heb ik ook verteld dat deze een laadbak heeft, een toilet, en een uitklapbare tent?
Ik ben eigenlijk alleen op zoek naar een gewone personenauto
- En de mogelijkheid om voor een amfibie-uitvoering te kiezen?
Ik zit normaal alleen op de weg eigenlijk
etc.
Hoe geeft een hoop extra ongebruikte zooi een databaseoplossing een streepje voor? Ik heb dit echt nooit begrepen.
In tweede instantie omdat je dit (het schakelen tussen databases) in de praktijk echt nooit zult gebruiken. Dit is gewoon onzinnig. Waarom zou je dit in een productieomgeving doen? Tenzij jouw applicatie data trekt uit meerdere (mogelijk externe) bronnen die verschillende database-typen hebben, hoef je hier geen implementaties voor te schrijven. PDO is ook niet geschreven voor enige specifieke database. Dit ligt in de drivers verankerd. En daar bijt het "in de praktijk nog even wat queries aanpassen" je enorm in de staart, want hier zit het echte werk. Het is ook helemaal niet gegarandeerd dat de drivers ondersteuning bieden voor hetgeen je met een query wilt bereiken, daar is mogelijk database-specifieke ondersteuning in de driver voor nodig (LIMIT-statement bijvoorbeeld, zit dit in alle database(driver)s die PDO ondersteunt?). Dit kun je simpelweg niet rijmen met de (wat mij betreft onzinnige) aanpak waarbij je vrijelijk zou kunnen schakelen tussen databases.
Wat ik wil zeggen, is dat wanneer je dingen in een database gaat 'programmeren' je vastzit aan die database. De database is dus als het ware een vast, niet-uitwisselbaar, onderdeel geworden van je applicatie.
Zijn ORMs / (database) abstractielagen hier niet bij uitstek voor bedoeld? Deze zorgen voor een (ont)koppelingslaag tussen database of ander opslagmedium en de applicatie. Op die manier zijn databases/opslagmedia wel "vrij uitwisselbaar", maar voordat je dat doet denk je hier ook wel twee keer over na, en test je het vervolgens drie keer, en vervolgens schakel je over naar één nieuwe aanpak, en niet vijf of twintig.
Then again, zo'n extra laag introduceert ook weer overhead. Zo'n (enterprise-)aanpak heb je niet echt nodig als je voor de lokale shoarma-toko een website/applicatie maakt.
Is dit niet zoiets als je beklagen over een beperking in je vrijheid die in wezen eigenlijk helemaal geen beperking vormt? Je kunt niet eindeloos dingen abstract houden, op een gegeven moment moeten er concrete acties (opslaan+uitlezen van data) plaatsvinden.
2020091113151330
Voordat je een custom formaat gaat breien lijkt het mij beter om eerst te kijken of je dit kunt oplossen met standaard datatypen.
Misschien wil je ook niet je gekozen formaat zo vasttimmeren dat deze enkel op dezelfde dag kan plaatsvinden. Indien je evenementen op een uniforme wijze wilt behandelen zijn een start(datum)tijd en een eind(datum)tijd wellicht handiger. Wat voor restricties je hier vervolgens op loslaat staat hier in principe los van. Ik ben het met je eens dat het een handig gekozen type/formaat dient te zijn, maar dat wil niet zeggen dat je deze zo kiest dat het enkel aan de stricte validatie voldoet, en verder weinig tot geen andere gebruiksmogelijkheden heeft.
>> In eerste instantie omdat je dit normaliter nooit doet. Je ontwerpt een applicatie niet om vervolgens de optie open te houden
Je bedoelt "jij" ontwerpt een applicatie niet om ... er kunnen bedrijven, systemen, frameworks zijn die zo'n optie wel graag bieden. Daarnaast gaat het om het PRINCIPE van OOP dat dingen uitwisselbaar zijn.
Wat betreft het hele stukje over die auto? Ik snap je vergelijking eerlijk gezegd totaal niet.
>> Zo'n (enterprise-)aanpak heb je niet echt nodig als je voor de lokale shoarma-toko een website/applicatie maakt.
Daarom zei ik ook "Dit hangt van je toepassing en (toekomst)verwachtingen af."
>> Ik ben het met je eens dat het een handig gekozen type/formaat dient te zijn, maar dat wil niet zeggen dat je deze zo kiest dat het enkel aan de stricte validatie voldoet, en verder weinig tot geen andere gebruiksmogelijkheden heeft.
Good lord ... ik geef gewoon een mogelijk opzetje. Wat de topic starter daar uiteindelijk mee doet en hoe hij het aanvliegt is aan hem. Ik probeer hem gewoon concreet even op weg te helpen. Jij betere voorstellen? Prima ... werk het even uit en laat het zien zou ik zeggen.
Je bedoelt "jij" ontwerpt een applicatie niet om ... er kunnen bedrijven, systemen, frameworks zijn die zo'n optie wel graag bieden.
Er is een verschil tussen wat een pakket mogelijk out-of-the-box biedt, en wat voor code je zelf allemaal aan het kloppen bent die je ooit op enig moment nodig denkt te hebben (spoiler: in beide gevallen gebruik je 90% waarschijnlijk niet).
Ozzie PHP op 17/09/2020 00:18:12
Wat betreft het hele stukje over die auto? Ik snap je vergelijking eerlijk gezegd totaal niet.
Allemaal extra ongebruikte functionaliteit maakt iets niet beter. Gebruik je MySQL? Prima, kies mysqli. Gebruik je iets anders: alsjeblieft, hier heb je PDO en veel plezier met het leren van de driver.
Ozzie PHP op 17/09/2020 00:18:12
ik geef gewoon een mogelijk opzetje. Wat de topic starter daar uiteindelijk mee doet en hoe hij het aanvliegt is aan hem. Ik probeer hem gewoon concreet even op weg te helpen. Jij betere voorstellen? Prima ... werk het even uit en laat het zien zou ik zeggen.
Ik geef al meteen een mogelijke tekortkoming aan. Maak gewoon gebruik van volledige datums- en tijden? Ook al heb je al die informatie op dit moment nog niet direct nodig, je hebt jezelf dan niet op voorhand vastgeprogrammeerd op het moment dat je hier anders mee om wilt gaan. Ook als je dadelijk wellicht queries wilt uitvoeren waarbij je begintijden wilt opvragen zul je deze uit dit formaat moeten peuteren met wat, substring functies ofzo? Weet niet of je TS hiermee helpt.
>> in beide gevallen gebruik je 90% waarschijnlijk niet
90% waarschijnlijk niet ... daar zeg je het al. Je doet een aanname en het geldt dus per definitie niet in alle gevallen. Maar eigenlijk was dat ook mijn punt niet. Het punt is dat je in OOP (dat is de gedachtegang) het ene "blokje" kunt uitwisselen voor het andere "blokje". Wie dat doet en waarom lijkt me voor deze discussie niet relevant.
>> Allemaal extra ongebruikte functionaliteit maakt iets niet beter.
Dat zeg ik ook nergens.
>> Maak gewoon gebruik van volledige datums- en tijden?
Dat is wat lastig als je een specifiek tijdsvak van een kwartier (gekoppeld aan een dag) moet kunnen selecteren in een drop down menu. Vandaar mijn voorstel, wat overigens ook niet meer was dan dat. Again ... als jij een beter voorstel hebt om een waarde voor een tijdvak te genereren, laat dan zien hoe. Ik heb gewoon een optie aangedragen. Als jij een betere variant weet dan zou ik die vooral plaatsen.
