strings inlezen in een database
Voor de database maakt het niet uit of een string uit meerdere regels bestaat.
Maar HTML5 maakt onderscheid, via <input type="text"> en <textarea>.
Ik heb overwogen om alle text- en varchar-velden van de database maar om te zetten naar textarea.
Maar soms maakt het mij wel uit of een tekst op een enkele regel staat, zoals bij een persoonsnaam.
Wat is een handige manier om het in de database aan te geven, zodat er bij het automatisch bouwen van het formulier rekening kan worden gehouden?
- Vanuit de database genereer ik een "definitie" bestand (om niet elke keer dat ik een formulier genereer de database lastig te moeten vallen). Hierin worden de DB kenmerken naar invoerveld-kenmerken vertaald (type, max. lengte, wel/niet verplicht, enz). Tijdens deze vertaalslag heb ik al een limiet van wat nog als "single line" veld (input type="text") wordt gezien, en wat sowieso een "multi-line" veld (textarea) wordt (instelbaar, maar de default waarde = 128). Na elke aanpassing aan de DB draai ik dit script om een nieuwe "definitie" te genereren (gewoon een PHP bestand met een multi-level array: tabel > veld > properties).
- Daar overheen kan ik dan nog een "afwijkingen" laagje leggen. Aan het postcode veld voeg ik bijvoorbeeld de regex-voorwaarde /^\d{4}\s*[A-Z]{2}$/ toe - dat soort dingen. En daar kan ik dus ook voor tekstvelden nog specifiek afwijken van single/multi-line. Ook dit gebeurt in een PHP bestand met dezelfde tabel > veld > properties structuur.
Bij het genereren van het HTML formulier voeg ik beide "definities" dan samen met array_replace_recursive(), en met het resultaat worden dan de velden gegenereerd (waarbij ik in code dan nogmaals van de definitie af kan wijken, maar dat is eigenlijk niet meer de bedoeling - de definitie is leidend, want dan is het veld ook overal hetzelfde).
(kortom: ik doe het niet in de database, maar in de "tussenlaag")
Gewijzigd op 10/04/2021 16:00:42 door Rob Doemaarwat
Voor jouw oplossing presteert waarschijnlijk sneller dan de mijne.
Ik ben nog niet tegen een snelheidslimiet van de database aangelopen, misschien komt dat omdat mijn programma een webapplicatie is op een intranet met een beperkt aantal gebruikers.
Het liefst zou ik de metadata van de database gebruiken, omdat dat toch al leidend is.
De database krijgt dan de functie van metadata server. Het idee van een aparte metadata server is niet nieuw, ik weet dat verschillende leveranciers werken met een MOF. Nu hoef ik niet zover te gaan om MOF te implementeren, dat is in mijn geval verspilling van rekenkracht. Het zou al mooi zijn als ik de standaard metadatastructuren van de database kan gebruiken.
Je beschrijft eigenlijk twee dingen: je vult de standaard metadata van de database aan met een eigen laagje, en daarbij gebruik je caching via PHP-bestanden. Wat mij betreft kan caching later nog, als het nodig is.
Zoals ik het op dit moment voor me zie, is het niet kunnen gebruiken van regeleinden een extra voorwaarde aan een tekstveld. Logisch zou zijn om hiervoor een CHECK constraint te maken en deze uit te lezen. Het commentaar op de constraint kan ik dan gebruiken voor de foutmelding als iemand het toch probeert.
Het enige waar ik dan nog in moet voorzien is hoe mijn raamwerk de CHECK herkent. Aan de hand van de naam? Of een specifieke regex? Of misschien simpeler met een maximumlengte? (Velden met een enkele regel bevatten doorgaans geen duizenden karakters)
Een andere optie die ik heb overwogen is om voor formulieren eigen metadata aan te maken in aparte tabellen, zodat daar nog wat extra's in meegenomen kunnen worden. Of misschien moet het een combinatie van allebei worden?
Toevoeging op 11/04/2021 17:43:59:
Bij nader inzien blijkt dat Postgres in mijn behoefte voorziet met eigen datatypen.
https://www.postgresql.org/docs/current/sql-createdomain.html
Toevoeging op 11/04/2021 19:31:15:
Het eigen laagje kan in de database via een soort NoSQL oplossing als JSON in het commentaar, of als een enkele metadata tabel.
Maar het kan ook als SQL met eigen tabellen voor metadata. Voordeel is dat je de formulieren later kan editen vanuit de applicatie, en workflows kan toepassen.
In principe gaat het uitvragen van metadata snel genoeg, en de database heeft voor veelvoorkomende queries een cache, en per PHP request cache ik per tabel/kolom de opgehaalde gegevens. Bij mij staat de database nog op dezelfde machine met PHP, dus netwerk is nog geen bottleneck.
Ik zou alle formulieren kunnen cachen via serialisatie (dan is er toch nog een nut voor :-). Als ik het op sla in de database schiet ik er qua snelheid niet veel mee op ben ik bang. Tot nu toe is het belangrijker dat de metadata actueel is.
Ik denk dat ik er zo wel ben, die DOMAINs was een blinde vlek, dus in ieder geval bedankt voor het kunnen sparren.