SQL formázás

Van egy pár hasznos formázási szabály, amit érdemes betartani, amikor kódot írsz, és ez ugyanúgy érvényes az SQL kódokra is.

Természetesen itt is van legalább egy “hivatalos” standard, vagy ajánlás, amit követni lehet, a szabályok az írásmódtól a logikai részekig terjednek. Vannak eszközök is, amik arra specializálódtak, hogy kódokat formázzanak (vagy kifejezetten SQL kódokat, vagy többek között SQL kódokat is). Meg persze vannak a szokásos céges vagy adott csoporton belüli szabályok is.

Összeírtam, én mire szoktam figyelni, hogyan szoktam kezelni az SQL kifejezéseket. Szerintem nagy része általánosan használható, pár az én egyéni rigolyám, használjátok, amit hasznosnak gondoltok.

Konzisztencia

Az első egyből nem a formázásra magára, hanem kicsit a logikai felépítésre vonatkozik. Ha lehet, akkor egységesen alakítsuk ki az adatbázis kinézetét. Gondolok itt olyanra, hogy ha egyszer elkezdtük használni a CamelCase-t (pl. EmpolyeeConnection), akkor az egész adatbázison azt alkalmazzuk. Ha elkezdtük használni az aláhúzást (pl. employee_connection), ha csak simán beírjuk, hogy employeeconnection, vagy employeeConnection, akkor azt vigyük tovább.

Vannak erre is szabályok, vannak minden tábornak helyeslői, ellenzői, igazából ebbe nem is akarok beleszólni. De az fontos, hogy úgy vigyük tovább, ahogy elkezdtük. Egy adatbázis elnevezési szabályait viszonylag könnyen fel lehet mérni, de mérhetetlen fejfájást okoz, ha keresünk egy objektumot és az pont nem a szabályok szerint van elnevezve.

Elnevezés

Ha kicsit közelebb szeretnék menni, akkor ezeket viszont már ökölszabálynak lehet értelmezni.

Az egyik kedvencem a foglalt SQL kulcsszó használata táblanévnek vagy oszlopnévnek. Ki ne találkozott volna már olyan táblával, hogy order? Persze használhatjuk, simán meg lehet oldani, de miért nem Orders? Ami logikusabb is számomra, mert ez a tábla rendeléseket tartalmaz, többes számban. Sokan az ellenkezőjét mondják, legyen a tábla neve egyes számú. Ennek is megvan az előnye, de én azt mondom: csináld, ahogy jobbnak érzed, csak legyen konzekvens.

A másik kedvencem, ami viszont kapcsolódik az előző ponthoz is: foreign key-ként használt oszlopok elnevezése. Miért kell nekem fejből tudnom, hogy az orders.id az egyik táblában OrderID, másikban OrderId, harmadikban order_id néven szerepel? Az első kettő még nem is okoznak nagy gondot, ha nem vesszünk figyelembe pár spéci collationt, de a harmadik már dühítő.

Ugyanígy, ha egy Products táblában van egy Id és egy ProductId oszlop, akkor vagy emlékszem rá, hogy melyik a tényleges Id és melyik az identity oszlop, vagy meg kell néznem minden esetben.

Ésszerű keretek között használhatunk rövidítéseket. Azt mindenki érti, hogy ID. Talán még azt is, hogy OrdCustId. Azt viszont, hogy OrdCustConnWRepId nem biztos. De az sem üdvözítő megoldás, ha kiírjuk, hogy OrderCustomerConnectionWithRepresentativeId. Ilyenkor jöhet jól, ha szépen megkommentezzük a kódunkat és ne adj isten adunk egy megjegyzést magához az oszlophoz is az adatbázisban.

Tudom, hogy ezeket simán ki lehet védeni még tervezés közben, és minden normális világban ki is kellene.

Amit viszont nem tervezésnél kell figyelembe venni, hogy például az alias-okat is az adatbázis logikájának megfelelően nevezzük el.

Mert melyik a jobb, az hogy

from Customers as t1
inner join Orders as t2 on t1.Id = t2.CustomerId

vagy az elnevezéseknél rendes neveket használva, például

from Customers as cust
inner join Orders as ord on cust.Id = ord.CustomerId

Formázás

Először is: ne hagyjuk a sorokat nagyon hosszúra nyúlni.

select elsomezo, masodikmezo, otodikmezo, hatodikmezo, * from azentablam where otodikmezo = valami or hatodikmezo > 2

ennél mennyivel szebb, és olvashatóbb, hogy

select
    elsomezo,
    masodikmezo,
    otodikmezo,
    hatodikmezo,
    *
from azentablam
where
    otodikmezo = valami
    or hatodikmezo > 2

Egyszerű, egyértelmű, nem jár sok többletmunkával, mégis hasznos. Sokkal könnyebb átfutni, felfogni, értelmezni, ha legközelebb olvasod, vagy más olvassa a csapatból.

Másodszor: ha rendesen szintezünk a kódban, akkor nem lesz egy olvashatatlan massza. A különféle egymáshoz tartozó részeket tegyük egy szintre, ezzel is kiemelve, hogy az adott részre irányítsa a figyelmet, vagy éppen levegye róla, ha nem azzal akarunk foglalkozni.

Vannak, akik még ennél is tovább mennek és a kulcsszavakat egymáshoz igazítják (river). Én nem vagyok ellene, de kicsit feleslegesnek érzem.

select elsomezo,
       masodikmezo,
       otodikmezo,
       hatodikmezo,
       *
  from azentablam
 where otodikmezo = valami
       or hatodikmezo > 2

És légyszi, légyszi, tegyél szóközöket! Nagyon megkönnyíti az olvasást!

select elsomezo,masodikmezo
from azentablam
where
    otodikmezo=valami
    or hatodikmezo>2

SQL kulcsszavak

Sokan azt ajánlják, hogy az SQL kulcsszavakat írjuk mindig nagybetűvel, hogy kitűnjenek. Itt engem elvesztettek. Valószínűleg nagyon hasznos volt így írni a dolgokat “régebben”, de amikor a Visual Studio, az SQL Management Studio és a Notepad++ (ezeket használom a leginkább) simán felajánlja a kiemelést (highlight), nem látom sok értelmét ennek a szabálynak. A legtöbb szerkesztőben már van kiemelés, én használom is és gyorsan rááll a szemem.

Megjegyzések

Úgy veszem észre, hogy nem nagyon szoktuk (igen, én sem mindig) megjegyzésekkel ellátni az SQL kódjainkat. Pedig nagyon hasznosak tudnak lenni, ha nem csak valami szabvány fejléce van egy-egy lekérdezésnek, hanem részleteiben (de nem szájbarágósan) megkommentezték, hogy miről szól és mit akarna csinálni.

Szintén hasznos, ha van a kódban valami alap beállítás ami nem egyértelmű, egy olyan rész ami bonyolultabb, az utókor számára már nem egyértelmű… írjunk hozzá megjegyzést!

Objektumokhoz is tudunk megjegyzést tenni, amit az adatbázisban tárolhatunk és természetesen lekérdezhetjük. Erről kicsit később.

Pontosvessző

Kövezzetek meg, de én teszek a parancsok végére pontosvesszőt. Tudom, hogy a T-SQL boldogan elvan enélkül is, szépen dolgozik, okos. Mégis okozhat bizonyos ritka esetekben gondot és akkor nagyon nehéz megtalálni, hogy ez miért történt.

Nem törik le senkinek a keze, ha minden egység végére biggyeszt egy pontosvesszőt, viszont ezzel nem csak átláthatóbbá tesszük a kódot, hanem biztonságosabbá is.

Kód blokkok

Én szeretem kitenni a kód blokkok elejét-végét, nem szeretem a spórolást ebben az esetben.

if valami = masvalami
 update table ...

helyett

if valami = masvalami
begin
    update table ...
end

Lehet if, else, case, nested query, én használom a blokkosítást. Ez lehet egy begin-end páros, vagy simán csak zárójelek, hogy az adott egységet körbevegyem.

Záró gondolatok

Ahogy az elején írtam, én így használom. Mindenki azt vegye belőle figyelembe, ami a saját világképébe belefér. Nem kell minden áron bebiflázni valami szabályrendszert, és azt mereven alkalmazni. Mindig lesznek olyan esetek, amik éppen nem férnek bele, amik éppen csak kilógnak kicsit.