Darbu secība

Šis ir simtais ieraksts šai emuārā. Ievērojot šo apaļumu, gribējās rakstu mazliet īpašu un tad man ienāca prātā tradicionālā darbu secība, ko es itin bieži, piemēram, sevis lasītajos kursos mēdzu popularizēt. Atzīstos, ka neesmu šīs secības izgudrotājs, oriģināls ir pieejams šai grāmatā, es to tikai mazliet vispārināju un adaptēju 🙂 Tātad, izstrādājot programmatūru datubāzēm var izmantot šādu pieeju:

• Labāk nedarīt neko;
• Ja tomēr jādara, tad izmantojiet SQL;
• Ja nav iespējams paveikt ar tīru SQL, tad izmantojiet iebūvēto programmēšanas valodu (PL/SQL –  Oraclē, Transact SQL – SQL Serverī utt.)
• Ja to nav iespējams paveikt ar iebūvēto programmēšanas valodu, tad lietojiet kādu citu programmēšanas valodu – Java, C utt.
• Ja to nav iespējams paveikt ar Java vai C (vai kādu citu izvēlētu programmēšanas valodu), tad stingri pārdomājiet, vai neķerties pie kāda cita darba.

Iespējams, ka daļai lasītāju šī pieeja šķiet mazliet provokatīva. Varbūt pat viņiem ir mazliet taisnība 😉 Tomēr tikai mazliet. Tagad daži komentāri par katru no punktiem.

Labāk nedarīt neko

Kā var visātrāk kaut ko izdarīt? Pareizi – neko nedarot! Šeit, protams, ir būtiski atšķirt divas lietas – ļaunprātīgu slinkumu no nejēdzīgas centības. Abas šīs lietas rada ļaunumu, tikai, ja ļaunprātīgu slinkumu parasti visi pamana, tad nejēdzīgu centību daudz retāk, jo to maskē drudžaina rosība un it kā kaut kādi rezultāti. Mans onkulis reiz teica, ka “muļķis, tas ir slikti, bet izglītots muļķis – vēl daudz sliktāk”. Es varu tikai paturpināt šo domu tālāk, ka izglītots un centīgs muļķis ir ekvivalents atombumbai, kuras sprādziena un radītās nelaimes rādiuss ir tieši proporcionāls šīs personas atbildības un tiesību apgabalam.

Tagad atgriežoties pie koda un programmēšanas – kā viss augšminētais to iespaido? Tā, ka centīgs nejēga var uzrakstīt rindiņu rindiņas, kas pēc būtības ir nevajadzīgas un liekas. Man un jādomā arī citiem lasītājiem itin bieži ir nācies redzēt koda gabalus, kurus samazinot uz pusi vai pat vairāk, programma beidzot sāk strādāt kaut cik pieņemamā laikā. Tātad – droši vien dotais uzdevums ir jāpaveic un biznesa problēma kaut kā jāatrisina (ja vien Jūs neesat arī reizē analītiķis un projekta vadītājs, kurš ir tiesīgs pieņemt lēmumu problēmas risināšanu atlikt), bet atrisināšanu vajadzētu veikt iespējami optimāli. Ja kods relatīvi vienkāršai problēmai sāk veidoties garš, nepārskatāms un tā izveidei nepieciešams milzu laiks, tad visdrīzāk problēma netiek risināta pareizi. Tipiskākās lietas ko esmu redzējis – vienas un tās pašas darbības veikšana ntās reizes ciklā tā vietā, lai to veiktu tikai vienreiz, nevajadzīgu un lieku pagaidu struktūru veidošana un aizpilde, tā vietā, lai uzrakstītu vienu SQL teikumu, funkcionalitātes izstrāde, kura nevienam nekad (varbūt izņemot testētāju) nebūs vajadzīga, funkcionalitātes nevajadzīga sarežģīšana izgudrojot jaunus klibus divriteņus utml.

Izmantojiet SQL

SQL iespējas ir lielas un plašas. Tās jau sen pārsniedz ierakstu atlases iespēju no vienas tabulas pat MySQLā, nemaz nerunājot par tādām DBVS, kā SQL Server un Oracle. Tiesa gan, šeit ir viena problēma – pieredze un spējas. Ne visiem tā pietiek, lai izveidotu vienu (vai dažus) elegantu SQL teikumu, ar kuru var atrisināt doto biznesa problēmu. Zināšanu trūkums un pierastā procedurālās programmēšanas pieredze vedina iet vieglāko ceļu – uzrakstīt programmiņu, kas to visu izdara. Man ir nācies pat samērā pieredzējušiem cilvēkiem pēc teksta “nu šito jau nevar izdarīt vienā SQL teikumā” pierādīt, ka tomēr var. Nu, protams, šeit iespējams nevajadzētu iekrist otrā galējībā, ja SQL teikums ir uz 7 lappusēm, tad beigās jau ir aizmirsts, kas ir bijis sākumā un tādu SQL teikumu reizēm ir ļoti grūti pagrozīt, pamainīt un piespiest strādāt atbilstošā ātrumā. Bet, piemēram, tādas lietas kā skaits, pirmās pēdējās vērtības, grupēšana, skaits grupā, hierarhijas (ne MySQL gan), datu atlase no daudzām tabulām, un pat kredīta kalkulatoru ir iespējams izveidot ar vienu SQL teikumu. Kāpēc tas ir labi? Tāpēc, ka viens SQL teikums parasti ir īsāks nekā ntās procedurālā koda rindiņas līdz ar to ātrāk uzrakstāms, atkļūdojams un vieglāk uzturams. Otrkārt tas parasti strādā un izpildās daudz ātrāk nekā procedurālais kods.

Izmantojiet iebūvēto programmēšanas valodu

Katrai sevi cienošai DBVS (nu jau pat MySQL) ir iespēja rakstīt procedūras un funkcijas izmantojot iebūvēto programmēšanas valodu, piemēram, PL/SQL Oraclē un Transact SQL – SQL Serverī. Kāpēc ir vērts tās izmantot? Pirmkārt jau – lai no kuras vietas (aplikācijas) procedūra un/vai funkcija tiks izsaukta tā vienmēr darbosies tāpat un atgriezīs to pašu rezultātu un veiks tās pašas darbības. Tas, kas jau ir notestēts un atzīts par labu esam gan no funkcionalitātes, gan ātrdarbības viedokļa. Otrkārt manipulācija ar datiem notiek tur, kur tie atrodas. Tie netiek nekur vilkti lielā kvantumā pa tīklu, 90% atmesti, jo tos patiesībā nemaz nevajadzēja, pēc tam mazliet pamainīti un stumti atpakaļ. Tas viss notiek uz vietas maksimāli tuvu to atrašanās vietai. Treškārt lielākoties DBVS šādām procedūrām un funkcijām spēj pielietot papildus ātrdarbību uzlabojošas lietas, piemēram, jau eksistējošu SQL teikumu izpildes plānu, tiesību pārbaužu utml administratīvu (un tīri no biznesa viedokļa lieku) darbību neveikšanā atkal un atkal, bet tikai pirmo reizi izsaucot.

Lietojiet kādu citu programmēšanas valodu

Faktiski šis ir pēdējais sakarīgais solis, ko vajadzētu veikt. Diemžēl itin bieži reālajā dzīvē tas jau tiek darīts kā pats pirmais. Ir, protams, gadījumi, kad tehnisku vai organizatorisku iemeslu dēļ nav iespējams izmantot kādu iepriekšējos soļos minēto pieeju. Šeit nav daudz ko komentēt, katrai programmēšanas valodai ir savi objektīvi plusi un mīnusi, nemaz nerunājot par subjektīvajiem, no kuriem pats galvenais (un ļoti ļoti būtisks izvēles iemesls) ir šīs valodas pārzināšana un spēja pielietot.

Pēdējā alternatīva

Ja nevienā no Jums zināmajām programmēšanas valodām uzdevumu nav iespējams sakarīgi veikt, tad ir vairākas iespējas:

• uzdevums ir no sērijas “aizej tur, nezin kur, atnes to, nezin ko” un visprātīgāk būtu to vienkārši atmest;
• Jūsu pieredze ir nepietiekama un vienkārši jāmācās un tā jāpapildina darba procesā;
• Jūsu pieredze ir nepietiekama, vēlmes to papildināt nav – jāatrod vietnieks un jāķeras pie cita darba, iespējams tāda, kas nav saistīts ar programmēšanu, vai vismaz programmēšanu datubāzēm 😉