Šī ir otrā daļa rakstam, kurš tika iesākts šeit. Būs vēl arī trešā pēdējā daļa, kurā tiks paskaidrots, kādas potenciālas problēmas jūs nakotnē gaida, ja jūs veidojat nevis datu bāzi, bet datu izgāztuvi.
4. Nosaukumu vadlīniju trūkums
Parasti šī problēma iet roku rokā ar Sākotnējā projektējuma trūkums (3). Haotiski nosaukumi gan datubāzes objektiem, gan programmatūrā ir viens no labākajiem veidiem, kā rakstīt neuzturamu kodu. Tas rada pilnīgi nesapratni, par katru objektu ir jāpārliecinās, ko tas patiesi nozīmē, nav iespējams izmantot analoģiju, balstoties uz esošajām zināšanām. Nav tik būtiski kādas tieši vadlīnijas tiek izmantotas, kā tieši nosaukumu tiek veidoti, bet ļoti būtiski ir, lai jūsu projektā nosaukumu veidošanas vadlīnijas tiktu pieņemtas un pēc tam tās tiktu ievērotas.
Turpmākā lasāmviela:
1. http://www.gplivna.eu/papers/naming_conventions.htm – Nosaukumu veidošanas vadlīnijas Oracle tabulām, kolonām, indeksiem, ierobežojumiem u.c.
5. Visa loģika aplikācijā / datubāzē ir tikai tabulas
Visa jūsu aplikācijas biznesa loģika ir ārpus Oracle datubāzes? Jā? Tad kāda iemesla dēļ jūs iztērējāt tik daudz naudas par Oracle licencēm? Jūs noteikti būtu iztikuši ar MySQL. Kāpēc? Vienkārši tāpēc, ka Oracle piedāvātā funkcionalitāte salīdzinot ar MySQL ir daudz lielāka, un tas neapšaubāmi atstāj iespaidu arī uz ātrdarbību. Tas būtu apmēram tas pats, kā īrēt milzīgu māju, ar daudzām istabām un dažādu aprīkojumu, bet spītīgi izmantot tikai dzīvojamo istabu. Jūs nelietojat piemēram tualeti. Galu galā kāpēc lai lietotu, var taču iziet ārā dārzā un paveikt nepieciešamās lietas tur 🙂 Jūs nelietojat virtuvi, jo var taču tāpat ārā uz ugunskura. Un te nu lūk ir jautājums – vai tiešām jūs šādi rīkotos arī ar savu īrēto māju, par kuru esat samaksājis krietnu naudu, bet tās piedāvātās iespējas izmantojat tikai par dažiem procentiem? Tieši tāda pati situācija ir ar datubāzēm, jo sevišķi datubāzēm, kas nodrošina plašu funkcionalitāti. Jūs esat samaksājis tik daudz naudas un pēc tam labprātīgi sevi aplaupat.
Ja jūs meklējat brīnumu, ko sauc par datubāzes neatkarību, tad visticamāk jūs esat sasnieguši situāciju, kad jūsu aplikācija optimāli nestrādā ne uz vienas no izmantotajām datubāzēm Visa iebūvētā funkcionalitāte ir cik vien iespējams tuvu datiem un tas ir primārais iemesls, kāpēc tā parasti veic attiecīgās lietas labāk, nekā tās pašas iespējas ārpus datubāzes. Pēc iepriekšējās analoģijas tas būtu kā dzīvot dažādas arhitektūras mājās, bet izmantot vienalga tikai dzīvojamo istabu. Esmu pārliecināts, ka jūs nebūtu apmierināts ar šādu dzīves kvalitāti.
Turpmākā lasāmviela:
1. http://www.rittmanmead.com/2004/11/24/the-cost-of-database-independence/ – The Cost of Database Independence by Mark Rittman.
6. Daudzas personas jau ir pielikušas savu pirkstu datu izgāztuves veidošanā
Kopā ar Sākotnējā projektējuma trūkumu (3) un Nosaukumu vadlīniju trūkumu (4) visi projekta dalībnieki, kas papildina jūsu datubāzi, ir kā bars cilvēku, kas izgrezno jūsu māju gan no iekšpuses, gan ārpuses bez jebkādas kopējas idejas un katrs pēc sava prāta un talanta spējām. Ja jūs esat veiksminieks, var gadīties, ka rezultāts jūs apmierina, bet vairumā gadījumu, tas būs kaut kas tāds, kas iedzīs šausmās pat vislielāko flegmatiķi. Tieši tāda pati situācija ir ar datubāzēm. Ir daudzas konvencijas, standarti un vadlīnijas, ko ievērot un, ja vairāk kā viena tiek lietota jūsu datubāzē, tad katra nākošā palielina kopējo neskaidrības un nesapratnes līmeni. Tas visacīmredzamāk kļūst tad, kad jums nākas vienlaicīgi modificēt divus objektus, kas izstrādāti vadoties pēc dažādām vadlīnijām – ko tagad darīt, turpināt, tādā pašā jau iesāktajā garā un palielināt kopējo dažādību vai izvēlēties vienu no esošajām, tādējādi iegūstot moduli, kam puse izskatās vienādi, bet otra puse otrādi? Varbūt vēl kādu citu variantu?
7. Datubāzu objektu fiziskie atribūti
7.1. Datu integritātes ierobežojumu trūkums
Šī parasti ir visradikālākā Visa loģika aplikācijā / datubāzē ir tikai tabulas (5) forma vai arī vienkārši rezultāts absolūtai nekompetencei. Ja jums datubāzē nav datu integritātes ierobežojumu, tad tas ir tikai laika jautājums, kad jums būs bāreņu (orphan) ieraksti, dublicētas vērtības un nevēlamas vērtības. Agrāk vai vēlāk kāds pamainīs datus apejot jūsu aplikāciju, agrāk vai vēlāk kāds pat negribot atradīs kļūdu jūsu aplikācijā un jūsu dati tiks sabojāti.
Mēģinājumi aplikācijas līdzekļiem ierobežot, piemēram, unikālas vērtības kādā kolonā apriori ir gandrīz vienmēr lemti neveiksmei (vai arī risinājumi būs nepilnīgi), it sevišķi, ja jūsu aplikāciju vienlaicīgi lietos vairāk kā viens lietotājs 😉
Turpmākā lasāmviela:
1. http://en.wikipedia.org/wiki/Referential_integrity – Datu integritāte, no Vikipēdijas, brīvās enciklopēdijas;
2. Oracle® Database Application Developer’s Guide – Fundamentals, 6 Maintaining Data Integrity in Application Development;
3. http://tkyte.blogspot.com/2006/06/what-did-i-decide-on.html – The Tom Kyte Blog, some worst practises.
7.2. Šifrēti un neinformatīvi tabulu nosaukumi
Tabulas ar nosaukumiem tab1, tab2 un/vai kolonas ar nosaukumiem kol1, kol2 var pārvērst jebkura cilvēka dzīvi ellē. Tad jau labāk tabulu nosaukumi kādā matabelelendas valodā, vismaz ir iemesls uzzināt ko daži vārdi šai valodā nozīmē. Strādājot ar iepriekš neiepazītu datubāzi ir grūti atcerēties loģiskus nosaukumus, nemaz nerunājot par kol1 vai tab2. Katra tāda lietošanas reize nozīmē ieskatīšanos dokumentācijā vai cita veida pierakstos.
7.3. Klasifikatoru trūkums
Cilvēks spēj izlasīt un saprast informāciju, kas ir pasniegta daudzos un dažādos veidos. Cliēvks sēpj izloībt jgēu arī no dizeagn kļūidanas ifnomrācjias. Ar datu bāzēm un precīziem algoritmiem ir daudz sliktāk. Tiklīdz kā jums nāksies uzrakstīt kādu atskaiti par lietām, kas it kā datu bāzē glabājas, bet ir, piemēram, teksta laukā, tā momentāli radīsies lielas un pamatīgas problēmas. Pieņemsim, ka jūs vēlaties nopirkt auto ar elektriski paceļamiem logiem un meklējat tādus kādā no mūsu sludinājumu serveriem. Kā cilvēks es saprotu, ka el. logu pacēlāji, el. logu pac., Elektriski regulējami logi, el. Logi ir viens un tas pats, bet atskaiti ģenerēt uz šādiem tekstiem būtu krietni vien grūtāk. Patiesības labad jāsaka, ka visos lielākajos sludinājumu serveros ir iespēja atķeksēt pārdodamajam auto šo „ekstru” un iegūt vienu kopīgu tekstu visos sludinājumos, tiesa gan tas nekavē dažus censoņus tekstā ievadīt savus variantus. Protams arī klasificētas vērtības vien nenodrošinās korektu datu ievadi, piemēram, vienā no sludinājumu serveriem Opel Zafira bija klasificēta kā mikroautobuss, universāls un hečbeks, tai pašā laikā parasti tā visur tiek saukta kā minivens, bet šāda iespēja izvēlēties netika piedāvāta 🙂
Otra iespēja ir vienā laukā glabāt saliktus datus, piemēram, vārds un uzvārds. Agrāk vai vēlāk būs tādas iespējas, kā Jānis Bērziņš, Bērziņš Jānis, J. Bērziņš, Bērziņš J. un iespējams arī kādi citi varianti. Protams, ja jūsu biznesa vajadzības nekad neprasīs šos laukus sadalīt un atpazīt, tad viss ir kārtībā, citādi radīsies problēmas.
7.4. Nekorektu datu tipu lietošana
Visbiežāk novērotā grēkošana ir VARCHAR tipa lietošana NUMBER un DATE vietā. Tā rezultātā ir iegūts liels kļūdu potenciāls. Skaitļu vietā simboli, korektu datumu vietā 30. februāri ir tikai sākums. Turpinājumā kārtošana nez kāpēc notiks samērā dīvaini – vispirms ‘1’, ‘10’ un tad tikai ‘2’, nemaz nerunājot par to, kā kārtos datumus. Dažāda veida netiešo (implicit) konversiju sekas būs neoptimāli vaicājumu izpildes plāni. Lai no tā visa izvairītos ir jāizdara relatīvi vienkārša lieta – jāizvēlas atbilstošs datu tips katrai kolonai.
7.5. Haotiski indeksi
Šis ir vairāk fiziskais nekā loģiskais datu bāzes aspekts. Ja datubāzei ir vairāk vai mazāk tikai tie indeksi, kas tai reāli nepieciešami, tad ir vieglāk atrast kopējas datu pieejas shēmas. Ja datu bāzei indeksi ir veidoti haotiski un kā pagadās, tad pirmkārt tiek nevajadzīgi uzturēti lieki indeksi, kas palēnina DML (izņemot SELECT) teikumus, otrkārt – nav nekādas skaidrības kā tad aplikācija un/vai citas saskarnes iegūst datus.
Raksta pirmā daļa, trešā daļa.
Ierakstīja Gints Plivna 
Datubāzes 