Controle op input van database waardes
Pagina: « vorige 1 2 3 volgende »
Hij legt neem ik aan toch in de database vast in welke tijdssloten gereserveerd zijn? Dan kan hij dat toch opvragen uit de database?
Je zou het wel om kunnen draaien: eerst kijken of de tijd al gereserveerd is, en pas als dat niet het geval is kijken of de tijd wel is toegestaan.
Je zou natuurlijk ook alle vrije tijdslots alvast in de database kunnen zetten. Nadeel is dat je dan "in het voren" moeten gaan werken (hoe ver?). En als je dan het algemene schema wijzigt moet je ook al dit "voorwerk" weer gaan lopen corrigeren.
Als het goed is heb je van een dag al de begin- en eindtijd (of dat is een goede query om mee te starten). De gekozen tijd moet hier sowieso binnen vallen. Daarnaast betreft het intervallen van een kwartier. Dit zijn al twee controles op het formaat die je sowieso kunt uitvoeren voordat je (meer) vragen stelt aan de database. Vervolgens zou je nog een laatste query kunnen uitvoeren of het desbetreffende tijdsslot al gereserveerd was. Dit alles zou wel binnen een transactie moeten plaatsvinden lijkt mij, om het gevaar van een dubbele boeking in het geheel weg te nemen.
Volgorde bij verwerking is dus bijvoorbeeld:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
- controleer format tijdsslot (intervallen van een kwartier)
--- start voor de volgende stap ergens een transactie ---
- controleer of het tijdsslot binnen het rooster van de gekozen dag valt (query)
- controleer of het tijdsslot vrij is (query)
- schrijf tijdsslot weg
--- beindig transactie ---
--- start voor de volgende stap ergens een transactie ---
- controleer of het tijdsslot binnen het rooster van de gekozen dag valt (query)
- controleer of het tijdsslot vrij is (query)
- schrijf tijdsslot weg
--- beindig transactie ---
Indien een van de stappen faalt kun je deze hele riedel meteen afbreken.
NB wellicht moet je ook een voorziening hebben dat je kunt controleren of je met een uitzondering in het rooster te maken hebt (bruiloft, overlijden of feestdag oid) waardoor de vestiging niet open is op een bepaalde dag.
Gewijzigd op 12/09/2020 01:17:35 door Thomas van den Heuvel
Frank Nietbelangrijk op 08/09/2020 23:39:26:
>> Wat zou de use case zijn die de overhead rechtvaardigt?
- Lees Rob zijn reactie nog eens door
[...]
- Lees Rob zijn reactie nog eens door
[...]
Het verschil zit hem in mijn context. Ik heb wel de database tot eigenaar van de gegevens gemaakt. En het is dan wel zo handig om meteen gebruik te maken van het feit dat de database prima de autorisatie kan waarborgen. Ik heb niet genoeg tijd om dat wiel opnieuw in PHP uit te vinden. Zeker niet als er sprake is van meerdere tabellen met row level security. De database hoeft ook niet de hele tabel door te lopen, hij (of zij?) maakt gebruik van indices waardoor je het eigenlijk niet sneller kunt nabouwen in PHP.
Aangenomen dat je applicatie of website door meerdere mensen tegelijkertijd bezocht wordt kan je die waarden ook niet client-side of PHP side cachen voor controle, omdat die waarde in de tussentijd veranderd kan zijn, daarom zou je de twee stappen (controle en oplaan) binnen een transactie moeten doen.
Het wordt een ander verhaal als je de database behandelt als domme data-opslagplaats (stel, in het geval van MySQL) en via bijvoorbeeld ORM moeilijk gaat lopen doen. Toch is dat een veelgebruikt paradigma, maar het is niet mijn keuze. In een enterprise situatie heb ik liever een slimme database. De applicatie moet er altijd rekening mee kunnen houden dat er nog andere applicaties zijn die met dezelfde gegevens werken.
Wat ik me nog kan voorstellen is dat de database op een andere locatie zit in de infrastructuur, waardoor communicatie tussen PHP en de DB prijzig wordt in termen van netwerk I/O. Maar dan kan je beter die infrastructuur onder de loep nemen, dan iets handmatig in PHP gaan doen waar je een database voor hebt.
Ad Fundum op 14/09/2020 16:09:26:
Het wordt een ander verhaal als je de database behandelt als domme data-opslagplaats (stel, in het geval van MySQL) en via bijvoorbeeld ORM moeilijk gaat lopen doen.
Interessante woordkeuze.
Ik gebruik zelf geen ORM, maar het feit dat het bestaat wil waarschijnlijk zeggen dat het een toepassing(sgebied) heeft. Net zoals ik mij kan voorstellen dat ORM niet ieders cup-of-tea is, kun jij je misschien voorstellen dat "domme data-opslag" in veel gevallen (meer dan) afdoende is.
Maakt het nu echt uit waar validatie geschiedt voordat het de database in gaat? Bekommer je je dan niet meer om de vorm dan om het daadwerkelijke doel? Als het maar gebeurt, en zolang het maar consistent gebeurt, lijkt mij.
Ik denk ook niet dat de gemiddelde bezoeker hier op zoek is naar enterprise-oplossingen, die kennis en technieken zul je waarschijnlijk ergens anders moeten verwerven en dat vergt ook een stuk meer (gestructureerd) werk voor de persoon in kwestie.
Thomas van den Heuvel op 12/09/2020 01:14:22:
Dit alles zou wel binnen een transactie moeten plaatsvinden lijkt mij, om het gevaar van een dubbele boeking in het geheel weg te nemen.
Een transactie werkt hier niet omdat deze locken op row(record) level en een nieuw record (nog) niet bestaat en dus ook niet gelocked kan worden.
In dit geval kan je beter met lock tables werken.
Thomas van den Heuvel op 14/09/2020 17:22:01:
Maakt het nu echt uit waar validatie geschiedt voordat het de database in gaat? Bekommer je je dan niet meer om de vorm dan om het daadwerkelijke doel? Als het maar gebeurt, en zolang het maar consistent gebeurt, lijkt mij.
Ik denk ook niet dat de gemiddelde bezoeker hier op zoek is naar enterprise-oplossingen, die kennis en technieken zul je waarschijnlijk ergens anders moeten verwerven en dat vergt ook een stuk meer (gestructureerd) werk voor de persoon in kwestie.
Ik denk ook niet dat de gemiddelde bezoeker hier op zoek is naar enterprise-oplossingen, die kennis en technieken zul je waarschijnlijk ergens anders moeten verwerven en dat vergt ook een stuk meer (gestructureerd) werk voor de persoon in kwestie.
Ik kan me toch niet helemaal aan de indruk onttrekken dat bezoekers op deze site wel eens gewezen worden op gestructureerd werken en de betere oplossingen. En dat onderschrijf ik, want als je er moeite voor doet, loont het om het programma zo elegant mogelijk te maken. Je weet immers niet wanneer je nog eens met je eigen code geconfronteerd wordt.
En validatie moet inderdaad consistent gebeuren.
Ik heb het plezier gehad om jarenlang met MySQL te mogen werken. En daarbij heb ik vaak gedacht: 'waarom is dat nou niet gewoon goed geregeld in MySQL?'. Simpele dingen als een tijd opslaan met tijdzone, of dat een query ongemerkt niet klopt omdat er ergens een automatische cast heeft plaatsgevonden wat elk normaal mens ontgaat.
Toegegeven, je kunt in technisch opzicht alles bouwen met MySQL, inclusief de dingen die andere databases al lang hebben. Maar dat kost extra tijd. Ik denk dat dit de reden is waarom MySQL vaak gebruikt wordt als 'domme data-opslagplaats', aangevuld met ORM.
ORM doet wat andere databases doen, waarbij de controle plaatsvindt in PHP. Handig voor wie PHP machtig is, maar waarom zou je niet gewoon de native (en goedkopere) functionaliteit van de database benutten die er al is? Als ik zie dat bijvoorbeeld Doctrine metadata van data uit de database opslaat in de PHP comments, dan denk ik dat het wel een heel omslachtige manier is om gestructureerd te werken.
Kortom: alles wat je met data doet, kan sneller en beter in een database.
Beter, omdat je problemen vermijdt, zoals verkeerd gebruik van PHP string-functies die geen multibyte encoding zoals UTF-8 ondersteunen. Beter, omdat je bij de bron validatie en autorisatie kunt afdwingen, zodat je dat niet op meerdere punten moet doen wanneer je programma wordt gesplitst of als er meerdere applicaties bij komen die met de data moeten werken. Eleganter omdat het meer conform SRP is, dat dit alles al geregeld is nog voordat PDO verbindt met de database.
Als je dingen gewoon kunt inregelen in de database, ga dat toch niet opnieuw programmeren in PHP? Ik begrijp dat er historische redenen voor kunnen zijn, maar als we dan toch bezig zijn om het goede voorbeeld te geven vind ik dat we moeten stellen dat gegevensvalidatie het beste in de database kan plaatsvinden.
@ Ad Fundum
>> ... vind ik dat we moeten stellen dat gegevensvalidatie het beste in de database kan plaatsvinden.
Over wat voor gegevensvalidatie heb je het nu precies?
Je kunt in een database inderdaad veel regels vastleggen, en dat mag. Of het ook "het beste" is, hangt van je manier van werken af en van bepaalde verwachtingen. Heel zwart-wit, jij ziet een database als "beheerder" van je data. Een soort van applicatielaag die bepaalt wat wel en niet mag. Thomas ziet een database als simpele/domme opslagbron waar je data in stopt en weer uithaalt. Voor beiden valt iets te zeggen.
Ik denk echter niet dat je zomaar kunt stellen dat "gegevensvalidatie het beste in de database kan plaatsvinden". Dit hangt van je toepassing en (toekomst)verwachtingen af.
Je kent vast wel het principe in OOP dat je componenten makkelijk moet kunnen omwisselen. Dat geldt ook voor de opslag van data. 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.)
Stel dat we uitgaan van de database als domme opslagplaats dan gaat het bovengenoemde op. Ga je uit van de database als "beheerder" van data, dan heb je een probleem. Je zult alle regels die voorheen in de oude database waren ingesteld, moeten gaan overzetten naar de nieuwe database ... als die überhaupt over die mogelijkheden beschikt.
Laten we het nog wat gekker maken. Je wilt de data niet langer opslaan in een database, maar (om welke reden dan ook) in een tekstbestand. Nu heb je een probleem, want in een tekstbestand kun je geen regels toepassen. Je verliest daarmee dus je controle. Nu is dit niet een heel reële situatie, maar het gaat even om het principe.
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.
In het geval van de domme database stop je alle controles en validaties in PHP en weet je dat die altijd hetzelfde zijn en altijd zullen werken, ongeacht welke database of andere opslagmethode je eraan hangt.
Voor beide oplossingen valt wat mij betreft iets te zeggen. Waar je voor kiest hangt van je toepassing af. Kun je goed met PHP overweg en wil je ultieme controle in elke situatie, dan voldoet de database als domme opslagbron prima. Heb je een applicatie die vooral database driven is en waar vele partijen hun data uithalen, dan kan een 'geprogrammeerde' database uitkomst bieden. Je moet dan wel zeker weten dat je die betreffende database jarenlang gaat gebruiken en niet tussentijds gemakkelijk kunt wisselen. Daarnaast kun je je afvragen of al die externe partijen zomaar in jouw database moeten kunnen roeren, en of je in een dergelijke situatie niet veel beter een API hiervoor kunt inzetten waarin tevens de controles plaatsvinden.
Anyhow ... dit is hoe ik er tegenaan kijk.
Ozzie PHP op 16/09/2020 11:27:01:
Over wat voor gegevensvalidatie heb je het nu precies?
[...]
Je kent vast wel het principe in OOP dat je componenten makkelijk moet kunnen omwisselen. Dat geldt ook voor de opslag van data.
[...] wanneer je dingen in een database gaat 'programmeren' zit je vast aan die database. De database is dus als het ware een vast, niet-uitwisselbaar, onderdeel geworden van je applicatie.
[...]
Je kent vast wel het principe in OOP dat je componenten makkelijk moet kunnen omwisselen. Dat geldt ook voor de opslag van data.
[...] wanneer je dingen in een database gaat 'programmeren' zit je vast aan die database. De database is dus als het ware een vast, niet-uitwisselbaar, onderdeel geworden van je applicatie.
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.
Dat tegenargument had ik ook verzonnen, maar het gaat niet op. Want dat zou dan ook moeten gelden voor PHP, en het besturingssysteem.
Ik zit serieus te kijken om mijn PHP programma om te bouwen in Rust, maar dat zal nog lastig worden. Het is nog eenvoudiger om mijn PHP programma om te bouwen naar Windows, maar dat is meer met dank aan PHP. Van PHP kom je niet snel 'af' als je dat zou willen omwisselen. Misschien kan ik het beter omschrijven naar Haxe, dan kan je PHP wel net zo gemakkelijk verwisselen als een database.
Gelukkig kan je Linux nog eenvoudig draaien op een ander besturingssyteem, al dan niet gevirtualiseerd. Maar het blijft linux.
Ook databases kennen die optie: je kunt bijvoorbeeld via ODBC (langzamere) verbindingen maken met andere databases en daarvan data gebruiken.
'Waarom zou het belangrijk zijn om PHP in te kunnen wisselen?' zou je je kunnen afvragen. Dat is vrij simpel: PHP wordt onderhouden door vrijwilligers die zich voor maximaal 3 jaar aan een PHP-versie verbinden. Daarna krijg je geen ondersteuning meer op het gebied van beveiliging.
Dus als je je met een PHP programma wilt kunnen verbinden aan een klant, doe je een belofte die gebaseerd is op je eigen verwachting. En dat is soms best spannend, bijvoorbeeld na PHP 5.6 duurde het even voordat PHP 7 kwam.
Ter vergelijk: de database die ik gebruik (PostgreSQL) kent een ondersteuningstermijn van 5 jaar.
Dan zou je toch eerder de vraag moeten stellen hoe PHP in te wisselen.
Voor de duidelijkheid: ik ben ondanks de vele valkuilen van PHP nog steeds fan van PHP, zeker nu versie 8 er aan zit te komen.
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.
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?
Waar loop je op vast?
Quote:
of het formaat van een kwartier klopt
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.
Code (php)
Dan check of de tijd tussen de start en eindtijd valt.
Ozzie PHP op 16/09/2020 11:27:01:
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.
Quote:
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.
Quote:
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.
Gewijzigd op 17/09/2020 00:09:47 door Thomas van den Heuvel
Wat snap je niet aan 'in theorie'?
>> 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.
Ozzie PHP op 17/09/2020 00:18:12:
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.
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.
Gewijzigd op 17/09/2020 00:37:29 door Ozzie PHP
Pagina: « vorige 1 2 3 volgende »