Malziet aizvirzoties no konkrēti SQL Server. Ir daudz literatūras par to, kā būtu jāraksta labs kods. Piemēram "Clean Code", kurā 462 lapaspusēs aprakstīts, kā var uzlabot koda kvalitāti. Grāmata ir ar Java piemēriem, tomēr principi un vērā ņemamās lietas ir patiesas arī rakstot gan T-SQL, gan jebkuru citu kodu.
Par labo praksi SQL Server 2 raksti, kas līdz galam tomēr nepatīk:
http://www.cms.gov/DBAdmin/downloads/SQLServerStandardsandGuildelines.pdf
(turpat arī priekš oracle, "svaigāks" dokuments)
(turpat arī priekš oracle, "svaigāks" dokuments)
Kopīgās vadlīnijas rakstot T-SQL
- Piešķirot objekta nosaukumus, izmantot vadlīnijas, kas jau tiek ievērotas datu bāzē, kurā notiek izstrāde.
- Vienā valodā saukt visus datu bāzes objektus (Piemēram, 'upr_SetPVNLikme()' vietā 'proc_UzstaditPVNLikmi'). Lai arī izklausās vienkāršs likums, ar šo bieži ir problēmas.
- CamelCase Izmantot visur, izņemot prefiksus un saīsinājumus.
- Shēmas nosaukumu vienmēr rakstīt pirms Objekta nosaukuma (piemēram, dbo.TabulasNosaukums, dbo.fn_GetPrice(), utt- Norādi shēmas nosaukumu!)
- Neizmantot zvaigznīti '*' visu kolonu atlasīšanai (piemēram, Select * From dbo.MyTable). Tas var radīt gan grūti noķeramas kļūdas, gan ātrdarbības problēmas.
- SQL Lietotāju definētus tipus (šos) nelietot bez galējas nepieciešamības. Lai arī kāds varētu šim nepiekrist, tomēr nemainīgas lietas mainās, līdzi sev pavelkot sarežģītas manipulācijas kodā.
- Skripti, kurus izpildīs atkārtoti vai izpildīs citi:
- Vienmēr sākas ar komentāru par to, kas ir autors, kad izveidots un ko skripts dara
- Tiek norādīta datu bāze, kas tiek izmantot 'Use DBName;'
- Aprarakstīt procedūras, funkcijas, skatus, trigerus, norādot izveides datumu, autoru un īsu darbības aprakstu (ja koda darbība nav ātri saprotama). Pievienot izmaiņu vēsturi- datums, autors, izmaiņas pēc būtības. Tas atvieglo darbu, piemēram, ja strādā ar vairākām datu bāzes instancēm (izstrādes, testa, produkcijas vides) vai meklējot problēmu cēloni. Komentārus pievieno pēc parametru definīcijas, bet pirms 'As' atslēgvārda (Piemēram, skatiem).
- Semikols pēc katras T-SQL komandas. Atsevišķos gadījumos semikols ir obligāts (piemēram, pirms CTE With izteiksmes). Viss iet uz to, ka arvien biežāk tas būs obligāts.
- Jaunas rindas
- Jauna rinda, ja tā ir pārāk gara (neietilpst ekrānā);
- Pirms un pēc iekavām rakstot parametrus funkcijām, procedūrām;
- Deklarējot mainīgos, katru mainīgo deklarēt savā rindā (nevis 'Declare @stX int, @stY int');
- Pirms vaicājuma daļām (piem, Select.., From.., Where), ja vien vaicājums nav tik īss, ka ietilpst vienā rindā.
- Koda komentāri (TODO:)
- Komentārs tikai tad, ja nav acīmredzams, ko kods dara (vai ko tam būtu jādara);
- Komentārs var būt virs rindas/ām, par ko tas ir vai arī rindas galā, ja tas ir īss.
- Atkāpes
- Ja jauns koda bloks (Begin .. End, Begin Try .. End Try, iekavas un jauna rinda). Ja bloks iekš bloka, tad papildus atkāpes.
- Ja kods turpinās jaunā rindā, jo vienā rindā viss nesatilpst (piemēram, Select satur daudz kolonnu nosaukumu un tie nesatilpst vienā rindā).
- Tabulas nosaukumu veidot no lietvārda daudzskaitlī vai izmantot saīsinājums, priekšā var būt prefiks bez apakš svītras, kas nosaka objekta loģisko grupu (labāk izmantot shēmas). Primārās atslēgas kolonna (surogātatslēga) tiek veidota izmantojot tabulas nosaukums vienskaitlī + "ID" (identifikators, kas tiek ģenerēts). Ja primārā atslēga ir lietotāja ievadīta, tad tabulas nosaukums vienskaitlī + "Kods" (ja cita valoda, tad attiecīgajā valodā). Veidojot detaļu tabulas, tiek izmantoti galvas tabulas nosaukums (tātad- daudzskaitlī) + detaļu tabulas nosaukums. Primārā atslēga vienskaitlī padara tikai pēdējo tabulas vārdu. Primārā atslēga ignorē tabulas prefiksu, ja tādi tiek izmantoti, lai grupētu tabulas pēc loģiskās piederības. Daži piemēri:
- Tabulas nosaukums 'dbo.Klienti', tad primārā atslēga 'KlientsID'. Ja veido detaļu tabulas, tad tabulas nosaukums veidojas, piemēram, 'dbo.KlientiDarbi'. Primārā atslēga būtu 'KlientiDarbsID' (īpaša uzmanība uz primārās atslēgas nosaukumu).
- Tabula 'dbo.Krasas', tad primārā atslēga būtu 'KrasaID' vai 'KrasaKods'.
- Tabula 'dbo.KlasifKrasas' ('Klasif' kā prefiks tiek ignorēts, veidojot primārās atslēgas nosaukumu), tad primārā atslēga būtu 'KrasaID' vai 'KrasaKods'.
- Lietvārds var tikt lietots kā prefiks. Tādā gadījumā saglabājas iepriekš aprakstītie likumi, bet bez daudzskaitļa. Piemēram, tabula 'dbo.CenaIeraksti', pirmārā atslēga 'IerakstsID', cita tabula, 'dbo.CenaValutas', primārā atslēga 'ValutaID'.
- Vienu un to pašu saturošu kolonnu, visur saukt vienādi un izmantot tos pašus datu tipus (piemēram, 'ColorID' visā datu bāzē apzīmē skaitli no kāda konkrēta klasifikatora un neko citu. Nekādi ColorID_FK un taml., char(5) un varchar(5) viena satura laukiem dažādās tabulās nav pieļaujami)
- Lietojot saīsinājumus (alias), izmantot vienus un tos pašus, kur vien iespējams.
- Lietot prefiksu 'vw_', tādā veidā vienmēr zināms, ka dati tiek izgūti no skata, nevis tabulas.
- Skata nosaukumu veidot tā, lai tas pēc iespējas precīzi apraksta, kādus datus var izgūt to izmantojot.
- Primārā atslēga, kas visbiežāk ir arī klasterētais indekss tiek nosaukts izmantojot prefiksu 'PK_' + tabulas nosaukums (tas arī noklusētais, kā SQL Server veido indeksa nosaukumus).
- Pārējie indeksi, tiek saukti izmantojot prefiksu 'IX_' + tabulas nosaukums + '_' + kolonnas vai kolonnu saraksts, kas iekļautas indeksā (iekļautās kolonnas šajā sarakstā neietilpst).
- Indeksu nosaukumus bieži iesaka veidot tā, lai pēc nosaukuma būtu skaidrs ne vien tas, vai indekss ir klasterēts, bet arī vai unikāls, kādas kolonnas ir iekļautas, vai indekss ir uz ārējās atslēgas kolonnas bāzēts utt.
- Primārās atslēgas „PK_TabulasNosaukums” (šādi veidoti pēc noklusējuma)
- Ārējās atslēgas „FK_TabulaKurai_TabulaUzKuruAtsaucas” (šādi veidoti pēc noklusējuma)
- Noklusētos ierobežojumus un pārbaudes ierobežojumus var nosaukt lietojot prefiksu ('def_', 'chk_' attiecīgi), bet pieļaujams atstāt noklusētos nosaukumus (veidojot tabulu, var izveidot ierobežojumus arī nenorādot to nosaukumu).
- Unikalitātes ierobežojumus veidojot ievēro indeksu nosaukšanas vadlīnijas.
- Procedūras parametri, ja tādi ir, tiek definēti bez prefiksa, kas norādītu datu tipu. Parametru nosaukumi, kas tiek izmantoti datu filtrēšanai/vērtību uzstādīšanai ir tādi paši, kā kolonnas nosaukumi (izņemot specifiskus gadījumus. Piemēram, ja pirms kolonu vērtību mainīšanas, tās jāsalīdzina ar orģinālajām vērtībām. tādā gadījumā lieto prefiksus).
- Procedūras sākumā izsaukt komandu 'Set NoCount On;', ja vien nav īpaša vajadzība saņemt un apstrādāt informāciju par komandas iespaidoto rindu skaitu (katras komandas, ja tādu ir daudz).
- Procedūrā nepieciešamos lokālos parametrus definēt procedūras sākumā.
- Ieteicams nosaukums, kas apraksta procedūras darbību. piemēram, "ParskatsKlientuSaraksts" vai "IelasitKlientus".
- Procedūrai kā prefiksu nav ieteicams lietot "pr_" prefiksu, tas tiek izmantots sistēmas procedūrām.
- Vienmēr apsvērt, vai kursoram tiešām nav labāka alternatīva. Paturot prātā gan ātrdarbību, gan koda lasāmību, gan cik bieži to izmantos un cik laika rezultāta iegūšanai (piemēram, reizēm kursora kods ir daudz vieglāk uzrakstāms, bet tas lēni izpildās- reizēm tas ir gana labi).
- Vienmēr apsvērt, vai to pašu funkcionalitāti nevar iegūt citā, labākā, veidā.
- DML trigeru nosaukumus veido izmantojot 'tr_' prefiksu, tad tabulas vai skata nosaukums + '_' + trigera darbības laiku (Insert, Update, Delete- vai to kombināciju, piemēram, InsertUpdate). Piemēram, tr_Klienti_InsertUpdate. Dažkārt tiek ieteikts trigeriem piešķirt nosaukumus pēc to tipa ("instead of", "after").
- Paturēt prātā, ka DML trigerī Inserted un Deleted tabulās var būt vairāk kā viena rinda, pat tad, ja šķiet, ka netiks mainīta vairāk kā viena rinda vienā komandā.
- Nelietot trigeru rekursijas un izsaukšanas secības norādīšanas iespējas.
Nav komentāru:
Ierakstīt komentāru