Invantive SQL Conventies

SQL kent vele praktische implementaties gebaseerd op een solide, theoretische fundering. Leveranciers zullen uiteraard verschillen in de manier waarop ze deze theorie implementeren. Maar over het algemeen, wanneer je voldoende bent opgeleid wat betreft logica en wiskunde, kun je gemakkelijk je gegevensvragen formuleren in SQL.

Echter, SQL kan ook gemakkelijk worden misbruikt door deze toe te passen als een taal binnen scenario's waar dit niet past. Een Turing machine bouwen in SQL? Natuurlijk, dit is mogelijk, maar niet aan te raden. De sinus van een getal berekenen met uitsluitend SQL? Ga je gang, uitvoerbaar, maar ik zou aanraden om te wisselen naar een taal die beter geschikt is voor wiskundige formules.

En in de gevallen waar SQL wel een goede keuze is, zijn er meerdere manieren om tot een correct resultaat te komen en zelfs nog meer manieren om tot een ogenschijnlijk correct resultaat te komen.

De gekozen aanpak is vaak gerelateerd aan de leverancier-specifieke functionaliteit, zoals met Oracle 6, waar je alleen de rule-based optimizer had en zelfs lichtelijk verwarrende semantische overeenkomsten en verschillen had tussen '' en null.

Maar zelfs op een leverancier-specifiek platform zijn er een aantal vuistregels, die wanneer toegepast, de juistheid en onderhoudbaarheid drastisch verbeteren.

Gebruik Kolomindeling

Ondanks dat schermen steeds breder en breder worden, kun je nog gemakkelijker fouten in je SQL-code ontdekken door gebruik te maken van kolommen om je SQL-code in te delen:

select EXPRESSION
,      EXPRESSION
from   TABLE
where  BOOLEAN
and    BOOLEAN
and    ( BOOLEAN
         or
         BOOLEAN
       )
order
by     EXPRESSION

De eerste kolom bevat sleutelwoorden zoals select, from, update, etc. De breedte in karakters is bepaald door de lengte van het meest voorkomende sleutelwoord select plus een karakter voor de spatie. Sommige gecombineerde sleutelwoorden zoals order by zijn langer en worden daarom gesplitst over twee regels.

Scheidingstekens zoals de komma worden altijd in de voorvoegselnotatie aan de linkerkant van de regel geplaatst. Waarom? Omdat dit het gemakkelijk maakt een regel uit te commentariëreren met -- zonder na te denken, of het nu een uitdrukking vroeg in de lijst is, in het midden of aan het einde.

De and wordt ook als scheider beschouwd. Soms zijn de ge-ande argumenten simpel en kort, en in dat geval is het gerechtvaardigd om ze samen op een regel te plaatsen. Maar over het algemeen heeft elke and een bedrijfsachtergrond en het plaatsen hiervan op een eigen regel geeft je de ruimte deze zakelijke achtergrond te beschrijven als regelcommentaar voor de and.

De and en or zijn lastig te lezen en te begrijpen wanneer de evaluatievolgorde niet expliciet is aangegeven met ( en ). Verder is or-optimalisatie een op zichzelf staand probleem.

Type bij uitdrukkingen altijd een spatie achter een komma, dubbele punt, puntkomma, vraagteken en uitroepteken. Net als in het Nederlands. Dit duidt altijd een goede plek aan voor lijnonderbrekingen wanneer de code bekeken wordt op een apparaat met beperkte ruimte. Maar juiste spatiëring helpt het menselijk oog ook om de structuur te begrijpen.

Meer leren over de impact van indeling op de productiviteit van medewerker en risicobeheer? Alhoewel oud is mijn persoonlijke favoriet nog steeds: Ergonomics at Work door David J. Oborne vanwege zijn toegankelijkheid, goed gekozen voorbeelden en stevige theoretische fundering. Verkrijgbaar voor een paar euro op Amazon.

Kleine letters waar mogelijk

Een essentieel onderdeel van goed te onderhouden en te analyseren SQL-code is het gebruik van gemengde of kleine letters en niet hoofdletters. Wat? Ja, het is een essentieel onderdeel. Grondig onderzoek naar de productiviteit van een programmeur binnen onderhoud en coderen bij partijen als IBM en Microsoft laten zien dat dit een grote impact heeft op deze aspecten en daarom ook op kwaliteit en kosten.

Het menselijk oog scant niet ieder karakter individueel maar herkent de vorm van het woord. Deze twee representaties van een woord hebben soortgelijke vormen: IBM en HAL wanneer van een afstand bekeken. Beide bezetten een rechthoekig gebied. Maar deze twee zijn compleet verschillend: ibm en hal. ibm heeft een losse punt boven het eerste teken (het puntje op de 'i') en een verticaal uitstekend streepje boven het midden van de tekst (de stok van de 'b').

Gebruik daarom niet enkel hoofdletters, behalve wanneer je het gebruik ervan kan rechtvaardigen.

En zelf in het geval van gemengd hoofdlettergebruik, pas deze alleen toe wanneer dit consequent gebeurt. Om dezelfde redenen als eerder genoemd, het menselijk oog herkent myBestMethod en mybestmethod (of my_best_method) niet gemakkelijk als hetzelfde.

Commentaarstijl

Gebruik de commentaarmogelijkheden voor twee niet-verwante activiteiten:

• Uitleg over wat de code zou moeten doen in bedrijfstaalgebruik en/of het beschrijven van beweegredenen om te kiezen voor een specifieke benadering van implementatie.
• Als een stuk gereedschap voor 'refactoring' and 'debugging' van code, bijvoorbeeld wanneer het analyseren van de data zorgt voor discrepanties tussen de verwachtingen en de werkelijke uitkomst.

De opmerking voor de eerste vorm van activiteit is gewoonlijk blijvend van aard, waar de tweede vorm tijdelijk is. Om in staat te zijn grote stukken van de code uit te sterren tijdens de tweede vorm van activiteit, is het gemakkelijker om de /*..*/ stijl te gebruiken. Echter kan /*..*/ niet worden ge-nest, dus voor de eerste activiteitssoort is het beter om een andere vorm van 'uitsterstijl' te kiezen.

Gelukkig ondersteunt SQL ook de regel-opmerking modus met --. Daarom kun je het beste -- gebruiken voor opmerkingen over wat de code zou moeten doen en /*..*/ alleen voor 'debugging', 'refactoring' en analyse.

Inline Weergave

In de twee-kolom indeling hierboven beschreven, kun je uiteraard nog een inline-weergave hebben binnen een from-clausule, zoals:

select EXPRESSSION
from   ( select EXPRESSION
         from TABLE
       )

In deze gevallen formatteer je de inline-weergave ook in twee kolommen. Plaats vervolgens de inline-weergave in kolom 2 na de from, zodat je in werkelijkheid 3 kolommen hebt.

Spaties en Tabs

Hoe aanlokkelijk ze ook mogen lijken, het gebruik van tabs is niet verstandig tenzij je werkt in een erg beperkte omgeving. Historisch gezien is de TAB-toets iets dat kon worden teruggevonden op een typemachine om snel lange halen te maken. Maar de spatiëring varieerde per model typemachine en per fabrikant. Sommige typemachines waren flexibel, sommigen hadden harde instellingen.

Zoals ook met de overgang van paard-getrokken voertuigen naar auto's zijn sommige historische elementen voor het gemak van de overgang behouden en datzelfde geldt voor de TAB-toets. Op sommige platformen staat de TAB-toets voor een horizontale beweging met twee normale spaties, op andere voor vier en weer anderen springen naar specifieke horizontale plekken.

Daarom: gebruik geen TABs en spring in plaats daarvan per kolom in of met telkens twee spaties.

Alias Naamgeving

Een andere mogelijkheid om de kwaliteit van je SQL-code te verbeteren is het juist benoemen van aliassen. Er komt een dag dat je je eerste join maakt, waarmee je data samenbrengt vanuit meerdere sets/tabellen in een lijst. Op dat moment moet je steunen op je geest om te herkennen welke kolommen nu uit welke tabel komen. De Invantive SQL-engine probeert uit te zoeken of het een unieke overeenkomst is en zo de corresponderende tabel erbij te zoeken. Maar dat is geen garantie voor succes; de volgende die het moet onderhouden is natuurlijk minder slim dan jij (of niet zo'n nerd) en je opvolger zal misschien een kolom toevoegen aan een van de in de join gebruikte tabellen met een identieke kolomnaam die tot dusver nog uniek was.

Daarom zou je altijd aliassen moeten toevoegen aan kolommen wanneer je joins gebruikt zoals pjt.code in plaats van code.

Maar hoe construeer je zinvolle aliassen? Aliassen zoals t en a zijn nietszeggend en het gebruik van de volledige tabelnaam zoals ExactOnlineRest.Projects.Projects.code maakt het moeilijker je code te begrijpen.

Een praktische manier is om de alias de zakelijke inhoud van jouw data te laten reflecteren. De meeste SQL-tabellen stammen direct af van de originele entiteiten in het entiteit-relatiediagram, zoals Projects or TransactionLines. Om een zinvolle, beknopte en korte alias te verkrijgen, gebruik je de volgende aanpak:

• Neem de enkelvoudige vorm van de tabelnaam (Projects wordt Project en TransactionLines wordt TransactionLine).
• Gebruik een spatie in plaats van camel case of een laag streepje om individuele woorden op te breken (Project wordt Project en TransactionLine wordt Transaction Line).
• Wanneer het resultaat één of meer woorden heeft: neem de eerste letter van het eerste woord, de eerste letter van het tweede woord en de laatste letter van het laatste woord. Dus Transaction Line wordt tle.
• Wanneer het resultaat twee of meer lettergrepen heeft: neem de eerste letter van de eerste lettergreep, de eerste letter van de tweede lettergreep en de laatste letter van het woord. Dus Project wordt pjt.
• Wanneer het resultaat drie of meer letters heeft: neem de eerste twee letters en de laatste letter. Dus care wordt cae.
• Als al het andere niet lukt: paniekeer en kies zelf iets.

Het gebruik van dergelijke aliassen zorgt ervoor dat jij en anderen gemakkelijk de SQL-code kunnen begrijpen en gemakkelijker fouten en mogelijke problemen kunnen detecteren.