Šī 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.
Datubāzes 
[…] 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 […]
Par 5.punktu – negribu piekrist! Tas nav viennozīmīgi un viss ir atkarīgs no konkrēta gadījuma.
Ja pareizi saprotu, runa ir par DATU BĀZU vadību, un nevis par APLIKĀCIJU vadību vai arhitektūru. No tā izriet, ka primārā interese ir par DATU vadību – sākot ar to saglabāšanu, manipulēšanu un izgūšanu, un beidzot ar to aizsardzību, pieejamības nodrošināšanu un citādām datu apsaimniekošanas funkcijām.
Kad runa aiziet par biznesa loģiku, nozarē plaši izplatīta ir trīs līmeņu arhitektūra (arī Oracle kontekstā; ja jau šeit visos rakstos pieminēts Oracle 🙂 ) – datu līmenis (datu bāze), biznesa loģika (aplikācija) un prezentācija (UI).
Tātad, ja lietotājs vēlas sevi “ieslēgt” (lock-in) konkrētā piegādātājā, tas var lielāku vai mazāku daļu savas biznesa loģikas pārcelt uz datu krātuvi. Dažreiz (lai arī reti) var būt arī tādi gadījumi, kad konkrētu specifisku vajadzību efektīvi nodrošina tikai konkrēta DBVS, bet domāju, ka tas ir samērā reti salīdzinājumā ar visu pārējo vajadzību masu. Gluži kā ar mobilajiem telefoniem – tie ir pārgrūsti ar visādām “fīčam”, no kurām lielākais vairums izmanto tikai dažas – zvanus, telefonu grāmatiņu, sms…
Bet es neredzu tajā neko sliktu, ja lietotājs (vai aplikācijas ražotājs) uzražo produktu, kuram visa biznesa loģika ir pilnīgi nodalīta no DBVS, pie tam biznesa loģikai ir dziļi vienalga kas kalpo kā DBVS – Oracle, M$$QL, MySQL, PostgreSQL vai jebkas cits, kas nodrošina efektīvu DATU pārvaldību!
Ivar!
Pilnīgi piekrītu, ka tas nav viennozīmīgi, šajā pasaulē vispār nekas nav pilnīgi viennozīmīgi, ja neskaita to, a mēs visi mirsim, un vēl jo vairāk šīs manis uzskaitītās lietas 🙂 Es jau zināmu laiku esmu pieņēmis viedokli, ka IT nekas nav absolūts, bet tajā pašā laikā es uzkatu, ka ir nepieciešams apzināties tās sekas, labumus un sliktumus ko mēs dabūjam, pieņemot konkrētu lēmumu.
Tagad par visu pēc kārtas:
1) manā izpartnē biznesa loģika visefektīvak darbojas tad, ja to novieto pēc iespējas tuvāk datiem un nevis izliek kaut kur ārā sētā. Biznesa loģika parasti prasa jauno/koriģēto datu pārbaudi attiecībā pret esošajiem datiem un te problēmas kā minimums rodas tādas, ka:
– vazāt lielus datu apjomus no DB uz aplikāciju serveri ir trafika noslodze un laikietilpīgi
– ātrāk vai vēlāk kāds gribēs datus ievadīt/rediģēt/iegūt ar citiem līdzekļiem nekā mana MEGA aplikācija un tad vai nu viņš būs spiests lietot manas MEGA aplikācijas interfeisus (ja tādi vispār ir) vai arī ies pa taisno un datu bāzē potenciāli radīs bardaku, jo noteikti daļu biznesa loģikas palaidīs garām vai implementēs citādi nekā manā aplikācijā.
2) Oracle šeit visur ir minēta tieši viena iemesla dēļ – tāpēc, ka es ar to nodarbojos un pārzinu. Kā jau rakstu pašā blogā virsrakstā es būtu priecīgs, ja šeit piedalītos cilvēki ar MySQL, MSSQL u.c. db zināšanām. Pie tam prakstiski visas šīs ir loģiskas kļūdas, kam ir pilnīgi vienalga kāda DBVS ir apakšā.
3) Tagad par lock-in kādā piegādātājā. Lūk es gribu redzēt kaut vienu piemēru, kad kāds klients, kuram aplikācijas izmantotā db bija iekš DBVS X ir paņēmis un tādu vai citādu iemeslu dēļ mainījis izmantoto DBVS uz Y. Vienīgais iemesls, kurš varbūt varētu būt ir tāds piemēram kā Informix, kurš reāli ir miris.
4) Ar visu biznesa loģiku aplikācijā ir vairākas problēmas, no kurām 2 es jau minēju augstāk. Pie tam nevajag uztvert visas DBVS kā vienu un to pašu. Katrai no tām ir citi izstrādātāji, cita arhitektūra, piemēram, izpildot ilgu vaicājumu (atskaiti) Oraclē mēs iegūsim vai nu konsistentu skatu uz vaicājuma sākuma brīdi, bet MSSqlā, cik man zināms, ja vien sevišķi nenopūlas, mēs iegūtu rezultātu kurā būtu tā saucamie dirty read, tas ir citu lietotāju nenoCOMMITētie dati. Es nesaku ka kāda no tām ir sliktāka vai labāka, es saku, ka arhitektūra ATŠĶIRAS un ir CITĀDA. To neņemot vērā mēs:
– vai nu datu bāzi izmantosim kā data dump (tikai visprastākās operācijas un arī tād vēl nav garantijas, ka tās strādās visur vienādi)
– vai arī mūsu aplikācija strādās nekorekti.
Padomā, kaut vai par to kā var ierobežot pirmos n ierakstus kādā vaicājumā Oraclē, MySQLā, MSSqlā. Pirmajā būtu jāizmanto ROWNUM, otrajā LIMIT, trešajā TOP. Protams pastāv iespēja visu datu kopu aizpumpēt uz aplikāciju serevri un tur ieobežot, bet kas būs tad ja datu kopā būs kaut vai daži tūkstoši ierakstu un vienlaicīgi tādu gribēs izpildīt 10 lietotāji. Jebkurā gadījumā mēs nonākam pie DB specifiska līmeņa (layer), kas to kaut kā menedžē.
Jā es esmu ar mieru piekrist, ka tiek taisītas DB neatkarīgas aplikācijas, bet tas nav TEHNISKI pamatots lēmums, tas varbūt ir MĀRKETINGISKI vai jeb kā citādi POLITISKI pamatots lēmums.
Iesaku paskatīties, prezentāciju, kas minēta trešajā šī raksta daļā 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. Tur kā reiz ir šāds pirmais slaids:
The promise:
Write once
Deploy everywhere on anything
Less work overall
Un nākošā ir
The reality
Write Once
– For each database
– They are different
Deploy Everywhere on anything
– Deploy on specific dot releases
– Of specific databases
– On certain platforms
– (it is a support issue)
Less Work overall
– More work overall
Esmu pats šādas aplikācijas redzējis, kuras ir uztaisījuši cilvēki, kas daudz maz pārzin vienu datu bāzi (SQL Server), bet tad ir politisks lēmums, ka mēs supportēsim arī nākošo (šai gadījumā Oracle).
Mani šausmas māc to atceroties:
– kods bija absolūti neefektīvs, tāpat kā SQL Serverī tika izmantotam miljons funkcijas tā vietā lai tās loģiski apvienotu pakotnēs,
– pie lietotāju skaita, kas lielāks nekā ~5 un datu lieluma, kas vairāk nekā daži K ierakstu viss sāka bremzēt vienkārši nenormāli.
Tātad lai būtu efektīvs risinājums uz N datubāzēm, jums vajag priekš katras no tām taisīt savu virsbūvi, tam ir jāatrod cilvēki, kas šo db daudz maz pārzin. Ja jūs esat gatavi uz to ielaisties vai nu MĀRKETINGA vai citu POLITISKU iemeslu dēļ, kāpēc ne – tikai apzinieties tās sekas, kas jūs sagaida.
Es tomēr vairāk piekristu Ivara teiktajam:
Nozarē noteikti valda viedoklis, ka funkcionalitātei ir jābūt atdalītai no datu bāzes. Varbūt kāds datu bāzu piegādātājs varētu domāt savādāk, taču viņam ir savi ieme$li, kāpēc to sludināt. LU lekcijās par komponentbāzēto arhitektūru no pasniedzēja pat izskanēja viedoklis, ka PL/SQL un Transact-SQL ir sliktākās programmēšanas valodas, kas izdomātas, jo daudziem tiek sačakarēts prāts – sistēmas arhitektūra sanāk neviendabīga. Loģika sabāzta datu bāzē un tml. Toreiz biju aizrāvies ar stored procedures – darbā tā visi darīja – pateicu, ka pasniedzējs mudaks – neko nesaprot no jaunajām tehnoloģijām. Tagad pēc kādiem 3 gadiem domāju, ka viņam bija pilnīga taisnība.
Tagad par visu pēc kārtas:
>> 1) manā izpartnē biznesa loģika visefektīvak darbojas tad, ja to novieto pēc iespējas tuvāk datiem un nevis izliek kaut kur ārā sētā.
Ko nozīmē “visefektīvāk”? Visātrāk? Tas jau nav visefektīvāk. Kādi tad ir tie būtiskie ātruma zudumi, ja aplikācijas loģika atrodas uz blakus servera?
Jaunu un koriģēto datu pārbaudei kā reiz vislabāk ir notikt pie klienta, lai nevajadzētu veikt lieku roundtrip, kad atsaka datu bāzes līmenī.
Mūsdienās ātrdarbības problēmas visbiežāk lētāk sanāk risināt nevis ar bioloģisko robotu (tb cilvēku) iesaistīšanu, bet iemetot naudu dzelžos/infrastruktūrā – 80% gadījumu būs lētāk.
Ja jau visi gribētu, lai viss notiek ātri, tad mēs attīstītu ASM programmēšanu, bet nav dzirdēts, ka uz to pusi ietu.
>> – vazāt lielus datu apjomus no DB uz aplikāciju serveri ir trafika noslodze un laikietilpīgi
Ar cik lielu datu apjomu tad cilvēks uz viena ekrāna var normāli strādāt? Nebūs takš vairāk par pāris megabaitiem teksta, kaut gan šis ir ļoti strīdīgs jautājums.
>> – ātrāk vai vēlāk kāds gribēs datus ievadīt/rediģēt/iegūt ar citiem līdzekļiem nekā mana MEGA aplikācija
Tad ir jāizmanto jaunais modes kliedziens – SOA. Vai jātaisa public API vai kas tml.
Piedāvātajā risinājumā tā pati MEGA aplikācija sēž pie tabulas tā kā aizbēgt no viņas nav iespējams. Neviens jau nebūs tiks traks, lai laistu kādu citu pa tiešo klāt tabulām
>> 3) Lūk es gribu redzēt kaut vienu piemēru, kad kāds klients, kuram aplikācijas izmantotā db bija iekš DBVS X ir paņēmis un tādu vai citādu iemeslu dēļ mainījis izmantoto DBVS uz Y.
Esmu veicis pārejas MS SQL Server -> PostgreSQL vairākas reizes. Iemesls viens – SQL server procesora licence maksāja vairākas štukas un lētāk ir pa nedēļu uztaisīt pāreju. Ja kāds nav samudrījis 200 storētās procedūras ar kaudzi IFiem utt, tad pašu datu definīciju pārlikšana ir vienkārša. Jebkurā gadījumā esmu uztaisījis SQL Server storēto procedūru konvertoru uz PostgreSQL procedūrām, kas to visu diezgan vienkāršo.
>> Padomā, kaut vai par to kā var ierobežot pirmos n ierakstus kādā vaicājumā Oraclē, MySQLā, MSSqlā. Pirmajā būtu jāizmanto ROWNUM, otrajā LIMIT, trešajā TOP
Data persistance projekti kā Hibernate ir diezgan daudz – izvēlies, kurš patīk un lieto.
Vēl viens paradokss par nosaukumu vadlīnijām. Pilnībā piekrītu rakstītajam, grūti būtu nepiekrist – pats bieži palieku nikns, kad kāds nosauc nepareizi tabulu, lauku, dajebko. Saskaroties ar pasaulē populārāko ERP SAP tabulu bezloģiku un interesantajiem nosaukumiem (t001, vbap, vbak, MCH1 – ņem tiešām jebkuru no miljons tabulām), liekas, ka pasaulē tomēr valda mārketings nevis veselais saprāts.
>Nozarē noteikti valda viedoklis, ka funkcionalitātei ir jābūt atdalītai no
>datu bāzes.
Nu es tā vis neteiktu, es, piemēram, arī parstāvu šo nozari un tā nedomāju. Varu nosaukt veselu baru cilvēkus, kas tā nedomā, tā kā kā minimums viedokļi ir dažādi 🙂
Bet nu tai pašā laikā esmu strādājis projektos, kur visa loģika lielākoties bija aplikācijā un tāpēc es darbu nepametu 🙂
>Varbūt kāds datu bāzu piegādātājs varētu domāt savādāk, taču viņam ir
>savi ieme$li, kāpēc to sludināt.
Ja tas bija domāts attiecībā uz Oracle, tad principā tas ir tiesa tikai ļoti mazā mērā, jo Oracle ir savs Aplikāciju Serveris, kas maksā gana pamatīgu naudu un kur arī visu var darīt ārpus DB. Tā kā, ja kāds izmantotu gan Aplikāciju Serveri, gan DB tīri no licenču viedokļa nauda būtu vairāk 🙂 Tiesa gan man ir tādas aizdomas, ka Latvijā Oracle Aplikāciju serveris nav pārāk izplatīts.
>Tagad pēc kādiem 3 gadiem domāju, ka viņam bija pilnīga taisnība.
🙂 Es vēl joprojām sliektos uz domu, ka viņš ir mudaks 🙂
>Ko nozīmē “visefektīvāk”? Visātrāk? Tas jau nav visefektīvāk. Kādi tad ir
>tie būtiskie ātruma zudumi, ja aplikācijas loģika atrodas uz blakus
>servera?
>Jaunu un koriģēto datu pārbaudei kā reiz vislabāk ir notikt pie klienta, lai
>nevajadzētu veikt lieku roundtrip, kad atsaka datu bāzes līmenī.
Būtiskākie ātruma zudumi ir paciņas (SQL teikuma) aizsūtīšana uz serveri, dabū atpakaļ rezultātu, aizsūta atkal dabū atkal. Tipisks FOR cikls, tipisks IFs. Es nebūt nenoliedzu, ka nav nepieciešams pārbaudes veikt arī klienta galā, tikai ar to vien nepietiek.
Pie tam tīri datu ievade ir tikai viena neliela daļa no kopējās biznesa loģikas, kas aplikācijās mēdz būt nepieciešama. Kā minimusm vēl varētu minēt datu ievadi no ārējām sistēmām, dažādus batch procesus, atskaites, datu apmaiņu starp sistēmām utt.
>Mūsdienās ātrdarbības problēmas visbiežāk lētāk sanāk risināt nevis ar
>bioloģisko robotu (tb cilvēku) iesaistīšanu, bet iemetot naudu
>dzelžos/infrastruktūrā – 80% gadījumu būs lētāk.
Hmm īsti nesapratu domu kāds sakars cilvēkiem, db un datu loģikai aplikācijā, bet gribētu atzīmēt, ka sliktu aplikāciju, kur notiek jebkāda veida serializācija, nekādi dzelži neglābs, jo vienkārši visi 16 procesori un ntie I/O vadi gaidīs uz vienu useri, kurš domā vai dzer kafiju.
>Ar cik lielu datu apjomu tad cilvēks uz viena ekrāna var normāli strādāt?
>Nebūs takš vairāk par pāris megabaitiem teksta, kaut gan šis ir ļoti
>strīdīgs jautājums.
Lai noģenerētu pat dažus K teksta var mierīgā garā izprojektēt kaut kādu figņu, kas ir spiesta apstrādāt ntos megabaitus – piemēram vienmēr rādīt kaut kādus kopsavilkumus.
>Neviens jau nebūs tiks traks, lai laistu kādu citu pa tiešo klāt tabulām
Mhmm nekad nesaki nekad 🙂
>Esmu veicis pārejas MS SQL Server -> PostgreSQL vairākas reizes.
>Iemesls viens – SQL server procesora licence maksāja vairākas štukas
>un lētāk ir pa nedēļu uztaisīt pāreju. Ja kāds nav samudrījis 200 storētās
>procedūras ar kaudzi IFiem utt, tad pašu datu definīciju pārlikšana ir
>vienkārša.
Atļaušos minēt, ka tās noteikti nebija īpaši funkcionāli sarežģītas aplikācijas. Jo nu pa nedēļu uztaisīt pārēju kaut kam nopietnam izklausās traki fantastiski.
>Jebkurā gadījumā esmu uztaisījis SQL Server storēto
>procedūru konvertoru uz PostgreSQL procedūrām, kas to visu diezgan >vienkāršo.
Pats konvertoru? Tas izklausās traki nopietni. Moška ir vērts padomāt par produkta izlaišanu un $$ pelnīšanu? 😉
>liekas, ka pasaulē tomēr valda mārketings nevis veselais saprāts.
Pasaulē valda $$$ manuprāt vismaz 🙂
“Biznesa loģika” ir pārāk plašs jēdziens, jo tas var nozīmēt gan operāciju, kas veic kaut kādu darbu ar pāris ierakstiem, gan operāciju, kas manipulē ar milzīgām datu kopām. Dzelžaina turēšanās pie vienas vai otras politikas attiecībā uz biznesa loģikas izvietošanu var novest pie neefektīva darba.
Kas attiecas uz datu pārbaudi – to visbiežāk ir vērts veikt arī klienta galā, bet datu bāzē tā noteikti ir jāveic. Biznesa loģika un prezentācijas līmenis var mainīties salīdzinoši ļoti bieži, bet dati tiek izmantoti atkal un atkal…
Lūk labs piemērs, kāpēc datu validācija ir jāveic kā minimums NE TIKAI FORMĀ
http://xoled.neolain.lv/blogs/index.php?id=345
Gribētu šo to pakomentēt saistībā ar biznesa loģikas atrašanās vietu.
Pirmkārt tādiem projektiem kā interneta veikals vai mazs portāls visa loģika bez problēmām var būt iekš aplikācijas un tur kā likums parasti tiek izmantotas “mazās” datu bāzes, kurām līdzīgas valodas kā PL/SQL nemaz nav.
Manuprāt, šeit autors tomēr vairāk uzsvaru ir licis uz salīdzinoši lielām aplikācijām. Pirmkārt, ir jāsaprot kas projektā ir pats svarīgākais – aplikācija vai dati. Ja runa ir par Oracle datu bāzi, tad datiem vistuvāk stāv PL/SQL un tas ir pats organiskākais veids kā sazināties ar SQL un veikt datu apstrādi. Oskar, pasaki man lūdzu kurš no pasniedzējiem LU jums māca tādu sūdus, ka PL/SQL ir vissliktākā valoda? Pats esmu mācījies LU un varu droši teikt, Oracle kursi tur nav tie paši spēcīgākie. Kā var izteikt šādus apgalvojumus, to var darīt tikai cilvēki, kuriem ir mazs sakars ar Oracle un kuri nav izstrādājuši lielas sistēmas. PL/SQL ir ļoti spēcīga un advancēta valoda, ja to pareizi izmanto, tad tas ir ļoti liels bonus visai sistēmai, bet ja ar to nemāk rīkoties, tad, protams, ka tā vairs nav tiks spēcīga 🙂
Datu nekvalitātes vārdā, noņem lūdzu Gint tos aizpildītos laukus publicējot komentāru.
Khe, khe, Tev nebūs savu niku mainīt 🙂 Ja godīgi man ir lielas aizdomas, ka tā ir Wordpresa iebūvētā funkcionalitāte un es tur neko nevaru darīt. Pie tam, man jau personīgi labāk patīk, ka es esmu vienmēr lietotājs xxx, nevis šodien xxx un rīt yyy. Galu galā nav ko radīt mākslīgu iespaidu par daudzām personām, ja patiesība ir tikai viena 😉