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😉

9 Responses to Darbu secība

  1. Māris says:

    “manipulācija ar datiem notiek tur, kur tie atrodas. Tie netiek nekur vilkti lielā kvantumā pa tīklu”
    Atvainojos, ja nesaprotu tīkla uzbūves un pašam pie sevis griešanās principus, bet vai Oracle Net gadījumā ar datubāzi un klientu uz tās pašas mašīnas nestrādā pēc principa, ja man, sēžot auto priekšējā sēdeklī, jāpaņem ābols no tīkliņa, kas nolikts uz pakaļējā, tad es uzvelku dzelteno vesti (IP paketes čaulu), izkāpju pa priekšējām durvīm, atveru pakaļējās un paņemu ābolu?

  2. Gints Plivna says:

    Ja tiek lietota kienta-servera arhitektūra, tad tēlaini izsakoties tā ir, precīzāks apraksts ir piemēram šeit Understanding Oracle Net Architecture.
    Bet es šeit biju domājis saglabātās (stored) procedūras un funkcijas, kuras tiek saglabātas datubāzē un turpat arī izpildītas. How PL/SQL runs ir apraksts un bildīte kā tas notiek. Citās DBVS tas notiek protams mazliet savādāk, bet idejiski +- gan jau ka tāpat.

  3. Māris says:

    Kad procedūras ir labi izmantot? Saukt no SQL koda funkcijas, kuras pašas kautko selektē, skaitās bremze, pašam gadījies par to pārliecināties. Puslappusi garš sql palags, ja to izdodas pareizi un bez kļudām uzrakstīt, strādā ievērojami ātrāk (nedo’ dies’ pēc pāris gadiem tur kaut kas jāpamaina). Vai ir kāds labs grafisks tūlis, kas šādā palagā, piemēram, dažādi iekrāso daļas (selekts no selekta) vai vismaz iekavas?

    • Gints Plivna says:

      Ā un tātad par to SQL teikumu – gluži kā jebkurš cits kods arī SQL kods ir jākomentē, jo sevišķi, ja tajā izmanto viltīgas konstrukcijas. Jebkurā sarežgītākā kodā bez komentāriem pat pēc pāris mēnešiem ir problēmas orientēties🙂
      Man šķiet iekavas iekrāso relatīvi daudzi – kaut vai tas pats PL/SQL devloper, ko es pārsvarā izmantoju kā GUI rīku. Bet šeit lielākoties ir SQL teikums smuki jānoformē (identācija, klauzas atseviški utml), tad bez krāsām diezgan labi var iztikt.

  4. reņģis says:

    kā šādā skatījumā ietilpst ORM ietvari?

  5. Gints Plivna says:

    @Māris
    Procedūru lielākie plusi:
    – atrodas iespējami tuvu datiem, tādēļ lielākas datu apstrādes gadījumā ir maksimāli efektīvs paņēmiens
    – var iekodēt sarežģītu loģiku, kuru var izsaukt no n klientiem un vienmēr rezultāts būs tas pats (nevis kodēt to sarežģīto loģiku n vietās)
    – mazāk vazājam datus pa tīklu, tādējādi vairāk trafiks paliek filmu vilkšanai😉
    – var pielikt klāt jaunas nosacīti mūsdienīgas aplikācijas ir visām iespējamām UI izvirtībām nekopējot apstrādes loģiku atkal jaunā vietā
    Mīnusi:
    – atšķirīga programmēšanas valoda no aplikācijas valodas, līdz ar to 2 vides, 2 koda kopumi
    – jāpārzin ne tikai .NETs, PHP, vai kas nu tur, bet arī konkrētā DBVS programmēšanas valoda. Kaut gan teorētiski Oraclē var izmantot Java stored procedures un šķiet .NET saglabātās procedūras SQL Serverī. Praktiski nekad neesmu to darījis un diez ko neesmu dzirdējis/lasījis arī, ka kādi citi tā darītu…
    @reņģis
    Hmmm, es esmu diezgan skeptisks attiecībā pret ORM. Jau tas sākotnējais apsolījums, ko viņi dod – derēt jebkurai DBVS – ir kaut kas tāds, kas mani personīgi nevis piesaista šai lietai, bet absolūti atgrūž. Zinot to, ka katra DBVS ir savādāka, lieta, kas sola, ka vienlīdz labi strādās ar visām, pirmkārt apsola to, ka vienlīdz SLIKTI strādās ar visām, jo lietos tikai un vienīgi kaut kādas pamata līmeņa darbības, kas varbūt visās DBVS ir puslīdz vienādas. Šāda lieta nespēs izmantot konkrētās DBVS specifiskās iespējas, par kurām vismaz Oracle un SQL Server gadījumā Jūs būsiet samaksājuši nemazu naudu. Vienkārša analoģija – iedomājaties kāds cilvēks dažbrīd dzīvo pie vecākiem, dažbrīd savā mājā. Un virtuves plītis abās mājās atšķiras. Tā vietā, lai pielāgotos un izmantotu katras šīs plīts labās īpašības, viņš ēdienu gatavo ārā sētā uz ugunskura, jo tad nav atkarīgs no konkrētās plīts specifiskajām īpašībām. Visi pārējie par tādu cilvēku virzītu savu pirkstu uz deniņu rajonu to intensīvi grozot😉
    Tātad AFAIK ORM var derēt relatīvi vienkāršos gadījumos, lai izpildītu CRUD (create, read, update, delete) operācijas, pie tam vēlams pa vienai reizē un ar iespējami mazāk savienojumiem😉 Bet šādā gadījumā es atkal neredzu jēgu tai sarežģītībai, ko ORM papildus uzliek.
    Šeit piemēram, ir tēma par to.

    • reņģis says:

      triviālas CRUD darbības arī var būt piemērots mērķis vienkāršošanai ar DBAL, ja tās atkārtojoties rada vairāk sarežģītības kā ieviestu DBAL, un ORM ir OO vidē iederīgs DBAL paveids, tāpēc es nedomāju, ka tas ir risinājums bez problēmas, jo viss ir atkarīgs no konkrētā projekta. DBAL un ORM ietvaru galvenais mērķis jau nav atvieglot migrāciju starp DBVS, un vismaz konkrēti es ORM neizmantoju, lai taisītu DBVS agnostisku kodu, bet tāpēc, lai ievērotu DRY principu, atšķirībā no visām oldskūlīgajām sistēmām, ar kurām man ir bijis jāstrādā, kas bieži automatizē tikai pieslēgšanos datubāzei. tā ir skaidra nejēdzība, ja lielu sarežģītas sistēmas daļu veido viens un tas pats pārkopētais CRUD kods ar variācijām, un taisīt pašam savu abstrakciju tādos gadījumos arī visticamāk novestu pie kaut kāda pusizcepta rezultāta, tāpēc es izmantoju gatavu un stabilu ORM ietvaru.

      patiesībā, ja tā padomā, lielākā daļa darbavietu, kurās es esmu strādājis, varētu ietaupīt tiešām lielas summas, ja tā vietā, lai gadiem maksātu pilnas programmētāju algas par to, ka diendienā tiek manuāli ģenerētas variācijas vienam un tam pašam CRUD kodam, vienreiz to ģenerāciju automatizētu. manuālais faktors tajos gadījumos ir arī nozīmējis, ka regulāri ir tikušas ieviestas, teiksim, SQLi ievainojamības, jo izstrādātājam ir jāatceras filtrēt ievadi, bet ar prepared statements tas notiktu automātiski. tas arī ir nozīmējis, ka produkta kvalitāte ir kopumā bijusi sliktāka, jo ir bijis sarežģītāk vairākkārt izmantot kodu, it īpaši starp dažādiem projektiem. es to domāju tā, ka ar ORM vajag mazāk disciplīnas, lai veidotu modulāru kodu, kā bez

  6. Grrr says:

    Nu jau beidzot ir pienācis tas laiks, kad nelielām aplikācijām ir jēdzīgāk izmantot kādu programmēšanas ietvaru (framework), kas ļauj aprakstīt datu modeļus un to saiknes esošajā programmēšanas valodā.

    Labs piemērs šai pieejai ir Python valodas produkts Django.

    Framework ļauj definēt būtiskās relācijas starp datiem un nodrošina to mappingu uz atbilstošo DBVS, ievērojot platformas īpatnības (Oracle, Mysql, Postgres, etc).

    Nav nekas jauns, bet pirms gadiem desmit, kad pats intensīvāk darbojos ar datubāzēm un pirmoreiz ar šādām lietām saskāros, šķiet, lietojot Java, es par šādiem mēģinājumiem raustīju plecus, jo tas bija sarežģīti un tāpat ļoti ātri vajadzēja sākt lietot SQL.

    Nezinu, kā ar citām programmēšanas sistēmām, bet iekš Django tagad man SQL tieša lietošana, radot jaunu aplikāciju, vairs nav nepieciešama. Vismaz ikdienišķi JOINi un datu manipulācijas strādā kā pulkstenis ar framwork līdzekļiem.

    Pozitīvais ir tas, ka ir viena vieta, kur glabājas mans datu modelis, un man nav jāuztur, atsevišķi jāinstalē un jāatkļūdo dažādu valodu (Python un SQL) kods.

    Protams, vienmēr būs aplikācijas, kuru prasības būs pietiekami sarežģītas, lai gribētos lietot “native” SQL (ko Django, protams, arī ļauj).

    Taču paredzu, ka ikdienā pamazām SQL datubāžu pieprasījumu veidošana un piemērošana vairāk nobīdīsies uz legacy sistēmām un sistēmām ar speciālām prasībām, un darbs ar DBVS vairāk būs saistīts ar servera “tjūnēšanu”.

  7. Grrr says:

    Jā, pareizi, biju piemirsis, ka to sauc par ORM.🙂

Komentēt

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Mainīt )

Twitter picture

You are commenting using your Twitter account. Log Out / Mainīt )

Facebook photo

You are commenting using your Facebook account. Log Out / Mainīt )

Google+ photo

You are commenting using your Google+ account. Log Out / Mainīt )

Connecting to %s

%d bloggers like this: