Šī ir trešā un pagaidām pēdējā daļa rakstam, kurš tika iesākts šeit. Šai daļā ir apkopoti tie “ieguvumi”, ko jūs varat gaidīt no savas datu izgāztuves.
Datu izgāztuves sekas
Zemāk uzskaitītās potenciālās sekas protams nav pilnīgs uzskaitījums, tās ir spēkā tad, ja ir sliktākais scenārijs atbilstoši iepriekš uzskaitītajām datu izgāztuves pazīmēm. Tāpēc es ceru, ka ir maz tādas datubāzes pasaulē un Latvijā, kas atbilst pilnīgi visām šīm pazīmēm, vai sliktākajā gadījumā jums vismaz ar tādām nav jādarbojas 🙂 Pat ja jums tomēr nav īpaši paveicies un nākas ar kaut ko tādu darboties, jācer, ka jums izdosies kaut kā izkļūt no situācijas, piemēram, atrodot kādu, kas jau ir izpētījis šo datu bāzi, varbūt datubāze ir tik maza, ka to spēj izanalizēt jebkurš saprātīgā laikā, varbūt jūs varat pierunāt klientu sākt jaunu skaistu dzīvi bez vecajiem nevienam nesaprotamajiem datiem.
1. Attīstība un izmaiņas ir gandrīz neiespējamas
Jo vairāk jūsu datu bāze patiesībā ir datu izgāztuve, jo vairāk katra izmaiņa jums izmaksās.
- Ar 1. Dokumentācijas neesamība un 2. Vienīgā zinošā persona nesen mainīja darbu jūs nezināt KO mainīt;
- Ar 3. Sākotnējā projektējuma trūkums un 4. Nosaukumu vadlīniju trūkums jūs nezināt KĀ mainīt;
- Ar 5. Visa loģika aplikācijā / datubāzē ir tikai tabulas un 7.1. Datu integritātes ierobežojumu trūkums jūs nevarat būt droši, ka mazākā jūsu izmaiņa neizsauks neprognozējamas izmaiņas pavisam citur un vienkārši nenobeigs jūsu sistēmu.
Jūs esat nolemti būt kopā ar savu datu izgāztuvi un nekas cits neatliek kā lūgt Dievu, lai kāds neatrastu kādu kļūdu.
2. Migrācija (Datu konversija) ir gandrīz neiespējama
Pieņemsim, ka jūs esat sapratis, kādā ķezā esat iekūlies un nolēmis sākt jaunu skaistu dzīvi, tiesa gan no vecās sistēmas izgūstot ārā vecos datus. Sliktās ziņas ir tādas, ka īstas datu izgāztuves gadījumā tas var būt ļoti sarežģīti un robežoties ar manuālu darbu.
- Ar 1. Dokumentācijas neesamība un 2. Vienīgā zinošā persona nesen mainīja darbu jūs nezināt KO migrēt. Jūs nezināt, kurās tabulās un kolonās glabājas kādi dati, nav skaidrs kuri no tiem ir jāņem vērā, bet kurus var ignorēt, piemēram, tāpēc, ka kolona tabulā ir palikusi, bet to reāli neviens vairs neizmanto. Patiesību sakot jums nav skaidrs, ko vispār šis tabulu un kolonu jūklis nozīmē.
- Ar 5. Visa loģika aplikācijā / datubāzē ir tikai tabulas un 7.1. Datu integritātes ierobežojumu trūkums jums ir ieraksti bez nepieciešamās informācijas (jo nav NOT NULL ierobežojumu), jums ir bāreņu ieraksti, jums vairākās vietās glabājas viena un tā pati informācija, kas ir pretrunīga utt.
- Ar 7.3. Klasifikatoru trūkums un 7.4. Nekorektu datu tipu lietošana katrs lietotājs ir ievadījis datus kā viņam labpatika, tā vietā lai veiktu tiešu klasifikatoru pārkodēšanu jums ir jākasa ārā informācijas druskas no teksta laukiem. Tā vietā lai vienkārši iegūtu datumu, jums ir jāveic konvertācija no 5 dažādiem laika formātiem vienā un tai paša laukā, piedevām izdomājot ko darīt, ja tāds datums vienkārši neeksistē. Pats sliktākais scenārijs šai gadījumā ir tāds, ka jūs esat spiesti nolīgt kādu bariņu ar studentiem/melnstrādniekiem, kas manuāli iziet cauri visiem ierakstiem un tos salabo.
- Ar 7.2. Šifrēti un neinformatīvi tabulu nosaukumi migrācijas koda rakstīšanas uzdevums kļūst par murgu un katru vakaru jums sāpēs galva 🙂
Parasti tā visa rezultātā ar milzīgām pūlēm jums ir izdevies vismaz daļēji pārnest datus, bet visi lietotāji sūdzas, ka iepriekšējā sistēma bija labāka, jo tajā bija visi dati un tā pieļāva daudz lielāku rīcības brīvību (varēja dažus laukus ievadīt, dažus ne, varēja pierakstīt visu teksta laukā savā iemīļotajā formātā, tagad jāizvēlas kaut kādas predefinētas vērtības, lai papildinātu klasifikatorus, jāiet uz citām formām utt.).
3. Teorija, ka aplikācija ir galvenā vērtība nevis dati
Iespējams, ka datu izgāztuves biežākais cēlonis ir doma, ka galvenais ir aplikācija nevis paši dati. Šī diskusija laika gaitā uzpeld atkal un atkal. Es gan esmu redzējis tikai to, ka aplikācijas nāk un iet bet vēlme pēc vēsturiskajiem datiem paliek. Piemērs par man zināmāko Oracle datu bāzi. Es neredzu īpašu iemeslu kāpēc šodien nevarētu lietot to pašu datu modeli, kas tika saprātīgi projektēts deviņdesmito gadu sākumā versijā 7.X. Tai pašā laikā pa šo laiku ir mainījušās vairākas modes kā tad ir stilīgi un vajadzētu programmēt aplikācijas, piemēram,
- tekstuālas formas, kas tika izpildītas uz servera;
- klienta servera formas;
- 3 līmeņu arhitektūra, ar aplikāciju serveri neskaitāmās valodās, piemēram, java, php, .NET, kur katram ir savs adeptu bariņš.
Lielākajā daļā esošo projektu esmu redzējis vēlmes ielādēt sākotnējos datus no teksta failiem, dažādām vēsturiskām un ne tik vēsturiskām datu bāzu pārvaldību sistēmu datu bāzēm vai tās pašas DBPS iepriekšējā datu modeļa versijas. Visi šie dati tika ievadīti izmantojot kādu aplikāciju. Kur tās ir tagad? Izmestas vēstures mēslainē, neviens par tām neatceras, ja neskaita iespējams kāda izstrādātāja nostaļģiskas atmiņas. Bet to ievadītie dati bieži ir interesanti vēl joprojām. Diemžēl ja jums ir datu izgāztuves cienīga datu bāze, tad ir spēkā šī teorija, ka galvenā vērtība ir aplikācija, jo datus bez aplikācijas neviens nespēj saprast un apstrādāt.
Kopsavilkums
Datu izgāztuves simptomu neesamība negarantē, ka jūsu datubāzei nebūs problēmu. Bet pieļaujot šīs kļūdas jums būs problēmas, ko nav iespējams atrisināt (izņemot 7.5. Haotiski indeksi) ar skaņošanu, kešošanu, rakstot optimālākus SQL vaicājumus, lietojot bind (bind) mainīgos, iegādājoties „niknāku” dzelzi vai ko citu. Tās ir loģiskās kļūdas, kas bieži vien nozīmē datubāzes projektēšanu no sākuma un iespējams arī jūsu aplikācijas pārrakstīšanu no nulles. Ja jūs noteikti esat pārliecināts, ka kādu no šiem simptomiem jūs apzināti gribat pieļaut, tad pārdomājiet to vismaz divreiz un vismaz sev noformulējiet gan plusus, gan mīnusus jūsu izvēlētajai pieejai. Tas vismaz ļaus jums ielūkoties dziļāk iespējamās problēmās un iegūt jaunas lēmumu pieņemšanas prasmes 🙂
Turpmākā lasāmviela:
1. http://en.wikipedia.org/wiki/Anti-pattern – Anti-pattern, no Vikipēdijas, brīvās enciklopēdijas;
2. http://www.web-hits.org/txt/codingunmaintainable.html – Kā rakstīt neuzturamu kodu;
3. http://asktom.oracle.com/pls/asktom/f?p=100:8:3045776155360546::NO – Oracle Open World 2006 programmētāju un DBA slikto paradumu prezentācija, lielākā daļa no tām attiecas uz jebkuru datubāzi.
Raksta pirmā daļa, otrā daļa.
Datubāzes 
[…] uzrakstīt par šo lietu man ienāca prātā, lasot kārtējo lielisko rakstu par datubāzēm Datubāzu resurss latviski […]
Par 2. punktu – gribētos dzirdēt autora viedokli, kā tad labāk definēt šos datu integritātes ierobežojumus datubāzes līmenī, aplikācijas līmenī? Kāpēc, tieši tā ?
nebiju vēl izlasījis 3.punktu 😉
>Par 2. punktu – gribētos dzirdēt autora viedokli, kā tad labāk definēt šos
>datu integritātes ierobežojumus datubāzes līmenī, aplikācijas līmenī?
>Kāpēc, tieši tā ?
Tā kā 3šais punkts manuprāt tieši tomēr neatbild uz šo jautājumu, tad došu pāris visacīmredzamākos piemērus.
Pirmkārt lūdzu ievērot, ka:
1) runa iet par daudzu lietotāju vienlaicīgu datu apstrādi
2) es pastāvu uz domu, ka aplikācija X tomēr nebūs vienīgā kas vismaz ilgākā laika posmā darbosies ar manas DB datiem.
Tātad:
1) Unikalitātes ierobežojums – šādu ir ļoti viegli izveidot ļoti daudzās datu bāzēs. Neatkarīgi no tā no cik sesijām datus pievieno vai koriģē, vienlaicīgi 2 vienādas vērtības dabūt nav iespējams. Lai kaut ko tādu izdarītu aplikācijas līmenī, mani šausmas māc iedomājoties to darbu, kāds būtu nepieciešams, lai ar _garantiju_ jūs šādas vērtības datu bāzē nedabūtu.
2) Ārējās atslēgas – tieši tas pats scenārijs. Daudzlietotāju gadījumā abus augšminētos ierobežojumus ir triviāli izveidot katrā kaut cik saprātīgā DB, bet ļoti netriviāli aplikācijā. Pie tam pat ja jūs izveidosiet – šie ierobežojumi būs un paliks tikai aplikācijā un kāds ātrāk vai velāk ar savām netīrajām rokām to visu sabeigs.
un tomēr, izstrādātājs saka nelieku constraintu, jo cieš veiktspēja? Pa muti? 😀 Vai ir izņēmumi?
Nu kā jau teicu nav nekā absolūta šai pasaulē. Var darīt bīstamas lietas, ja apzinās to sekas.
Tātad ja kāds ir gatavs akceptēt to, ka viņam _ātri_ datubāzē tiks ievadīta draza, kāpēc nē, var arī tā darīt.
Es tomēr līdz šim esmu bijis pārliecībā, ka draza nevienam nepatīk.
Un ja arguments ir ātrdarbība – tad nu lūk ierobežojumu gadījumā es teiktu – dod testpiemēru. Lūdzu testpiemēru, kurā piemēram veic vairāku (desmitu) tūkstošu ierakstu ievietošanu ar ierobežojumu un bez tā. Izmēram starpību, izdalam uz ierakstu, parēķinam kāds ir potenciālais mūsu plānotais ierakstu ievades apjoms un iegūstam laiku – cik tad nu mēs zaudēsim. Lūk šeit es esmu pilnīgi pārliecināts, ka vismaz 9 gadījumos no 10 zaudējums laika ziņā būs absolūti niecīgs, bet potenciālais zaudējums datu kvalitātes ziņā būs daudz lielāks.
Latvijā ir tikai pāris projekti, kuriem tikai iespējams constraintu nelikšana varētu kaut kādā mērā palīdzēt. Un tik un tā iespējamās negatīvās sekas no šo constraintu neesamības ir daudzreiz lielākas nekā ieguvums no tās. Ja constraintu nelikšana ir kā sistēma, tad tur viennozīmīgi ir jānomaina programmētājs, jo tad tā tik tiešām būs datu izgāztuve. Pats esmu redzējis PHP programmētāju veidotas datu bāzes un tur ir vienkārši briesmu lietas. Vienīgais kas no constraintiem atrodas ir PK, pārējais viss ir nullable un teksta laukiem ir maksimālie garumi. FK, UK, Check constrainti ir ļoti vitāli un ja kāds saka ko pretēju tad iesaku turpmāk viņa ieteikumus vispār neuzklausīt.
Demokrātijas modelis tas ir.