Na 10 jaar niets te hebben gedaan, wil ik een nieuw (simpel) php project starten.
Ik ben uiteraard niet up-to-date, dus ik heb een beetje bijscholing en een eerste start-up nodig.
Oma is online :), maar denkt dat ze voor haar simpele projectje, met een beetje hulp, best wel weer uit de voeten kan.
Het is de bedoeling dat er een formulier kan worden ingevuld op diverse locaties, maar alleen door de ingelogde gebruikers. Het is niet de bedoeling dat het een open portal wordt, er zijn bepaalde gebruikers die gegevens kunnen en mogen invoeren.
Wat de gebruiker moet kunnen invoeren:
Locatie
Klantnummer
Geboortedatum
Datum invoer
Vraag > keuze A of B
Upload bestand > foto,pdf
Vrije tekst >
>> Na mijn mening hoort een formulier niet in een <table>
Oh ja ook dat is na tien jaar wel veranderd. We hebben <div>'s en we hebben tablets en smartphones op nummer één staan om mee te browsen. Dus nog meer huiswerk: responsive webdesign
Met backtics kun je helemaal vrij kolom- en tabelnamen kiezen.
Dus ook gereserveerde woorden, namen met spaties erin en dergelijke.
Dat is op zich leuk, maar het dwingt je om overal die backtics te gebruiken in al je query's.
Vergeet je die ergens, dan kan, zeker in het geval van gereserveerde woorden je query ineens een andere betekenis krijgen. In het gunstigste geval krijg je alleen een foutmelding.
SELECT FROM afzender FROM afzenders
dat kun je een valide query maken: er is kenneljk een kolom 'from' in je tabel 'afzenders' en die kolom alias je tot afzender
SELECT `FROM` afzender FROM afzenders
Maar we kunnen natuurlijk ook de tabel wel FROM noemen en er nog een kolom WHERE tegenaan gooien.
SELECT `FROM` FROM `FROM` WHERE `WHERE`
Dit is redelijk onleesbaar, maar al wel alle records ophalen waarvoor de kolom WHERE een waarde bevat
Dus als de regel hanteert om geen backtics te gebruiken, voorkom je automatisch ook dit soort ellende.
Andersom: MySQL introduceert steeds weer nieuwe functionaliteit, en dus komen er ook steeds meer gereserveerde woorden. Door al je eigen "woorden" dus tussen backticks te zetten weet je zeker dat je bij een toekomstige upgrade van MySQL (of misschien maak je wel iets wat op vele verschillende omgevingen gaat draaien) je niet opeens een kolomnaam (+ verwijzingen in code) moet gaan veranderen omdat MySQL je woord "gestolen" heeft (of alsnog van backticks moet voorzien ... ;-) ).
Overigens kun je het aantal backticks flink beperken door met aliassen te werken:
Maar backticks of niet het lijkt me toch handig om de gereserveerde woorden als tabel- of kolomnamen zoveel mogelijk te vermijden om verwarring te voorkomen.
Alternatief: gebruik een (unieke) tabel/kolom-prefix, dan heb je ook niet per se aliassen nodig en is het altijd compleet ondubbelzinnig over welke kolom je het hebt.
Deze en elk van de voorgenoemde alternatieven hebben zowel voor- als nadelen.
EDIT: een prefix is een (vast) voorvoegsel. Dus voor de tabel "users" gebruik je bijvoorbeeld usr_ als prefix. usr_id, usr_name etc, lijkt me duidelijk over welke tabel en kolom dat gaat. En om een beetje lijn te houden in database-ontwerp en naamgeving zou je kunnen besluiten om alles een drieletterige prefix te geven, of wat je zelf handig vindt.
