Dit is uiteraard wel verwarrend. Wat je ook zou kunnen doen is kolomnamen een standaard prefix (voorvoegsel) geven, die de tabelnaam min of meer reflecteert.
Bijkomend voordeel daarvan is dat alle kolomnamen uniek zijn. Dit kan ook handig zijn als je in queries tabellen combineert, dan heb je niet vijf kolommen met de naam "id" of "name" ofzo.
Dit is natuurlijk een kwestie van smaak / conventies. Wat je op zijn minst zou moeten doen of proberen is het vermijden van het gebruik van gereserveerde woorden.
Zoals ik al vermelde in mijn eerste post kan ik helaas de kolom naam niet veranderen.
Dit wordt gegenereerd door een veel gebruikt programma, daar heb helaas ik geen grip op.
Inderdaad een prefix is natuurlijk gewoon vele malen makkelijkere.. zoals COL_Call
Zoals ik al vermelde in mijn eerste post kan ik helaas de kolom naam niet veranderen.
Een issue op de bugtracker schieten, of een patch aanleveren in het versie-beheer is natuurlijk zo gedaan.
Ik denk dat de programmeurs daar ook wel blij van worden, als anderen welwillend meedenken of hun applicatie. ;-)
SELECT * FROM $db_table x WHERE x.Call LIKE '%$searchq%' ORDER BY x.QsoDate DESC, x.TimeOn DESC
Op deze manier kun je ook in joins (elke tabel z'n eigen alias) de boel uit elkaar houden, en hoef je niet elke kolom van een unieke prefix te voorzien.
Zelf heb ik nogal een hekel aan prefixen:
- je moet ze steeds intypen
- de boel "leest" niet lekker ("select iets from tabel" wordt "select whargarbl_iets from tabel")
- een mapping van kolommen naar object properties is "gedoe" (niet 1:1)
- bij een foreign key wordt het alleen maar complexer (wordt het dan prefixhier_prefixdaar_kolomnaam; of zonder de prefixhier, maar dan kun je bij joins alsnog niet zonder alias)
- een prefix wil je meestal kort houden (3 letters ofzo), maar als het project een beetje uit de hand begint te lopen (100+ tabellen) wordt het moeilijk om nog een unieke/duidelijke prefix te verzinnen
Wat handig is blijkt uit het gebruik, het is een middel om een doel te bereiken, het is geen doel op zichzelf.
Net zoals een alias een middel is, die in dit geval mogelijk handiger is omdat je blijkbaar met handen en voeten gebonden bent aan kolomnamen met gereserveerde woorden.
En over de argumenten hierboven: argumenten moet je niet tellen, maar wegen. Je zult zelf moeten bepalen hoe belangrijk deze voor jou zijn (en meestal toegepast op een specifiek probleem).
Dit gaat over Reserved Words en het is vreemd dat een standaard pakket of cms het woord CALL gebruikt......
Toch een beetje knoeiwerk, zeker het werken met backticks is armoe want ga je nu alleen CALL met backticks doen of werkelijk alle kolommen en tabellen in selects/updates/deletes? Backticks is een vervelende erfenis uit phpadmin ofzoiets, dat wil je toch niet?
Voor reserved words en keywords zie: https://dev.mysql.com/doc/refman/8.0/en/keywords.html
