eKase – valsts budžeta elektronisko norēķinu sistēma

Kāds Pods.lv lasītājs iesūtīja nelielu aprakstu ar ekrānuzņēmumiem no valsts budžeta elektronisko norēķinu sistēmas – eKase. Te būs neliels izrāvums no 2007.gada pārskata (2.26MiB PDF) par doto sistēmu, lai saprastu, kas tas ir.

Jau ceturto gadu valsts budžeta izpildes jomā Valsts kasē izmanto valsts budžeta elektronisko norēķinu sistēmu eKase, kas paredzēta Valsts kases pakalpojumu sniegšanai internetā. Ar eKasi Valsts kase nodrošina attālinātu pakalpojumu pieejamību budžeta finansētām institūcijām un pašvaldībām, vienlaikus garantējot nepieciešamo informācijas drošību un konfidencialitāti. Izmantojot eKasi, Valsts kases klienti var:
1) veikt maksājumus;
2) pārbaudīt maksājumu rīkojumu izpildes rezultātus;
3) saņemt finanšu informāciju par kontu stāvokli, valsts budžeta finansēšanas plānu izpildi, kontu apgrozījuma izrakstus un kontu mēneša kopsavilkumus.

Daži dati par to cik daudz lietotāju ir šai sistēmai.

2007.gadā sadarbības līgumus par eKases sistēmas izmantošanu noslēguši 192 klienti un kopā eKases sistēmas pakalpojumus izmanto 1462 klienti ar vairāk nekā 4000 lietotājiem. Kopējā ar eKasi veiktā latu plūsmas maksājumu attiecība pret kopējo latu plūsmu ir 62%. 2007.gadā, salīdzinot ar 2006.gadu, par 6% pieaudzis ar eKases sistēmu apstrādāto maksājumu skaits. Šo maksājumu pieaugumu veicinājis pakalpojuma lietotāju skaita pieaugums.

Nu un te ir solītie ekrānuzņēmumi. Visi ir ar lielākām bildītēm.

1. Kad ienāk sistēmā parādās šis logs. Viss interesantākais jaunumos ir “Datora noskaņošana darbam ar eKases sistēmu.” Kā viņu skaņot, tas gan lai paliek katra ziņā. 🙂

2. Darbs ar sistēmu no sadaļas palīdzība.

3. Maksājumu saraksts netiek uzreiz rādīts vai atlasīts kaut kādā veidā pa kontiem. Lai atrastu vajadzīgo ir nepieciešams zināt ievades datums vai arī aptuvenais mēnesis vai gads. 🙂 Apstrādes statuss norāda kurā stadijā pašlaik ir maksājums. Akceptējums – šai bankai ir nepieciešami divi cilvēki, viens kurš ievada un apstiprina P2 (otrais paraksts) un cilvēks bez ievadīšanas iespējām, kurš apstiprina jaunievadītos maksājumu uzdevumus P1 (pirmais paraksts) un nosūta tos tālākai apstrādei, ko loģiski veic vēl viens cilvēks, bankas darbinieks.

Par vairāk cilvēku ievadi. Doma ir tāda, ka maksājumu uzdevumu ir jāapstiprina diviem cilvēkiem, pieņemsim grāmatvede un biedrības vadītājs. Arī ja maksājumu uzdevumu iesniedz drukātā veidā, tad ir nepieciešami šo te divu cilvēku paraksti. Tāda pati doma ir arī eKasē, kad ir divi cilvēki, kas tad elektroniski apstiprina/paraksta šo te maksājuma uzdevumu. Viens no šiem cilvēkiem, teiksim grāmatvedis, var ievadīt jaunus maksājumu uzdevumus, bet otrs tikai apskatīt un apstiprināt, kā arī nosūtīt tos tālāk uz banku. Bankā ir tā, ka ši te valsts kase nosūtītos pieprasījums apskata un apstiprina, no 9.00-17.00 darba dienās. Bez bankas darbinieka apstiprināšanas maksājums nenotiek.

4. Maksājuma ievadīšana. Mūnusi: automātisks maksājuma numurs (Swedbank), Karu reizi ir jānorāda konta numurs no kura skaiti naudu, reizēm gadās aizmirst nomainīt konta numuru. “Summas sadalījums pa EEK”  – skaista lieta, kad tev kodi ir jāzina gandrīz no galvas, jo viņu palīglīdzeklī aprakstītie kodi dažreiz arī nav pareizi.

5. Nākamais logs.

6. Tā izskatās maksājumu saraksts. Kurus var izdrukāt, diemžēl vēl neesmu sapratis, kādus printera uzstādījumus tur jāliek, lai viss tiek izdrukāts korekti.

7. Maksājumu paraugi, šeit daudz maz viss ir normāli, kaut gan pamanīju vienu lietu, ka viņiem nav vēlreiz pārjautājamā jautājuma par dzēšanu, ja nu nejauši uzkliko uz vārda dzēst, ko tad?

8. Šī iespēja nav pārbaudīta – varbūt strādā.

9. Maksājuma fails.

10. Jauno maksājumu akceptēšana.

11. Kopsavilkums. Kontu saraksts ar naudas atlikumu bez jebkādām citām lietām.

12. Konta pārskats, šeit gan ir daudz variāciju, bet nesaprotu, kur kad kādu ir jāizmanto. 🙂 Datni var saglabāt gan RTF gan HTML.

Ja atradu pareizo atsauci, tad pēc Valsts informācijas sistēmu reģistra datiem eKase tika izstrādāta tālajā 1999.gadā.

Tehniskie parametri un datu bāzu raksturojums
Oracle datu bāze un aplikācija
Projektēšanas un izveidošanas izmaksas
Ls 170365.45 budžeta finansējums
Uzturēšanas izmaksas
Izmaksās iekļautas arī izmaksas, kas saistītas ar jaunas funkcionalitātes (papildinājumu) izstrādi.
1999.gads Ls 145721.20 budžeta finansējums;
2000.gads Ls 37397.77 budžeta finansējums;
2001.gads Ls 28307.55 budžeta finansējums;
2002.gads Ls 41155.09 budžeta finansējums;
2003.gads Ls 73186.69 budžeta finansējums;
2004.gads Ls 41655.60 budžeta finansējums;
2005.gads Ls 45798.16 budžeta finansējums;
2006.gads Ls 73055.40 budžeta finansējums;
2007.gads Ls 62304.00 budžeta finansējums.
Spriežot pēc šī dokumenta datiem, šogad plānotie un samazinātie izdevumi.
143 000 latu – samazināti uzdevumi Ministra kabineta atbalstītam prioritārajam pasākumam “Budžeta pārskatu sistēmas izstrāde un jaunas elektronisko norēķinu informācijas sistēmas eKase ieviešana” (Ministra kabineta 2007.gada 3.septembra sēdes protokols Nr.48 1.§), mainot projekta ietvaros veicamo darbu apmaksas grafiku (kapitālie izdevumi);
Kā jau pamanījāt, tad sistēma ir diezgan veca un labā ziņa ir tāda, ka nākamā gada budžetā (Microsoft DOC) bija plānots uzlabot esošo sistēmu.
2008 2009 2010
Budžeta pārskatu sistēmas izstrādei un jaunas elektronisko norēķinu informācijas sistēmas eKase ieviešanai 169 000 429 000 129 000

Ja pareizi sapratu, tad arī attiecībā uz izmaiņām 2009.gada budžetā, eKase sistēmas izstrādes izmaksas ir samazinātas uz pusi.

260,0 tūkst. latu – Budžeta pārskatu sistēmas izstrāde un jaunas elektronisko norēķinu informācijas sistēmas eKase ieviešanas turpināšanai (kapitālie izdevumi);

Man šķiet, ka diezgan ciešami izstrādāta sistēma. Ja skaita, ka tā tika veidota pirms 9 gadiem un joprojām veiksmīgi darbojas. Neliels kosmētiskais remonts, pāris funkcionāli uzlabojumi un sistēma izskatīsies kā jauna.

Lielākā daļa no visām izmaksām visticamāk, ka veidojās no dārgajiem serveriem un Oracle datubāzes licencēm. Nebrīnīšos, ja tur apakšā arī būs kāds komerciālais risinājums, kas nav no lētajiem, jo toreiz jau vēl nebija tik attīstīti bezmaksas atvērtā koda risinājumi.

Interesanti apskatīties kā desmit gadu laikā ir augušas izstrādes izmaksas. Ja toreiz par izstrādi nācās atpogāt 170 tūkstošus, tad tagad par uzlabošanas darbiem plāno jau 260 000Ls.

28 thoughts on “eKase – valsts budžeta elektronisko norēķinu sistēma

  1. Anonymous Coward

    eKase.. eKlase whatever.. piem eKlase uz FF norm nestradaa kaukaadas tur fishkas negaaja. shobriid neaceros kas tieshi, bet nu taa vinjsh ir.

    Atbildēt
  2. prx

    Tad redz ar ko nodarbojas Biedrība Dienvidlatgales NVO atbalsta centrs! Analizē sys darbības principus par kuriem tai nav lielas sajēgas. Būtu vismaz manuāli izlasījis 🙂

    Atbildēt
  3. koko

    Pēc izskata nenormāli līdzīgs VIDa EDS, bet nu – izskatas varētu būt mānīgs pie tam pa to EDS es ļoti daudz neesmu ņēmies.
    Mani mūsdienās šokē tikai viena lieta – kāda mārrutka dēļ pusotram tūkstotim reālu klientu ir nepieciešams Oracle? Vai tiešām pa šiem 9 gadiem tā datubāze ir uzaugusi līdz miljoniem ierakstu?

    Atbildēt
  4. ev

    tiešām “padzeltens” ieraksts – ibanka kā ibanka, pie tam šauram, specifiskam lietotāju lokam.
    http://www.kase.gov.lv/?object_id=1550
    http://polsis.mk.gov.lv/view.do?id=2021
    šobrīd šķiet tiek migrēta uz SAP, ar Fidavista atbalstu utml
    un jā – ja jau valsts konsolidētais budžets ir pāri pa 5 miljardi, tad ieraksti datu bāzē pat viena gadā laikā būs, khm, padaudz 🙂

    Atbildēt
  5. gerard

    Oriģināls:
    Nebrīnīšos, ja tur apakšā arī būs kāds komerciālais risinājums, kas nav no lētajiem, jo toreiz jau vēl nebija tik attīstīti bezmaksas atvērtā koda risinājumi.

    Komentārs:
    Stāstīt par lielajām izmaksām jau ir viegli. Uzbūvēt kaut ko sakarīgu un lietojamu uz atvērtā koda – kaut kas cits. Praksē sanāk nedaudz lietot arī pāris atvērtā koda risinājumus – vienīgā atšķirība ir kāposts, kurš ir nolikts par šo risinājumu – tas ir mazāks nekā maksas produkts. Ērtums, kļūdu daudzums, uzlabošanas iespējas – nu tāpat kā lielajiem produktiem: ērtums brīžiem klibo ļoti nopietni, kļūdas ir visur – kur cilvēks pieskarās un tās brīžiem netiek labotas mēnešiem (tā sakot – kamēr nav kritisks vai kamēr šefs nesāk kliegt – ir jau labi), uzlabošanas iespējas – ar baru programmētājiem jau visu ko var paveikt, taču praksē kaut kā tas nenotiek bieži.

    Es brīnīšos, kad kāds beidzot uzrakstīs par analogu bezmaksas atvērtā koda risinājumu, kurš strādā un kur būs pamaoti redzams ka viņa ekspluatēšana ir lēta, kā arī, pats par sevi saprotams, netiks no specifikācijām izņemta vesela virkne noderīgu lietu un risinājums būs savietojams ar nopietniem dzelžiem. Varbūt ir vērts uzrakstīt kādu rakstu (būtu interesanti izlasīt rakstu sēriju, bet nu būsim reāli) par to, kā atvērtais kods praktiski ierullē un ar pirkstu norādīt kāds maksas risinājums tika izspiests. Subjektīvi – īpaši interesanti būtu izlasīt par praksi saistībā ar, piemēram, ERP risinājumiem, dokumentu pārvaldi, bet gan jau ir ne tikai šīs divas jomas 🙂 Citādi sanāk, ka visi runā, bet praksē apskatīt kaut ko vairāk par openoffice nesanāk. Žēl, taču būsim reāli – vienkāršo lietotāju atsauksmes ir ļoti viegli dabūt par to, ka “atkal tas Windows karās”, taču tas tā ir tīri vēsturiski, ka skaļi netiek lamāts kāds opensources softs, lai cik līks tas nebūtu, jo lietotāji par to nemaz neiedomājās 😉
    Domāju, ka daudziem būtu noderīgi arī palasīt par pieredzi ar atvērtā koda supportu – pieņemu, ka daudzi ir sadarbojušies ar Microsoft vai kādu citu milžu supportu – un stādās priekšā, ko tas nozīmē. Bet par atvērtā koda supportu kaut kā vēl mazāk sanāk dzirdēt. Bet supports mūsdienās ir kaut kas vairāk par padomu pārkompilēt kerneli.
    Risinājuma piemērs, kas izskaudis Oracle maksas risinājumus aizstājot ar atvērtā koda risinājumiem tepat LV – tas izraisītu ne tikai cieņu, bet gan jau daudziem arī profesionālu interesi un būtu ļoti noderīgi.
    Tādas pārdomas.
    Katrā ziņā raksts interesants un izlasīšanas vērts, paldies!

    Atbildēt
  6. CooLynX Raksta autors

    gerard, līdz šodienai vēl var paspēt piereģistrēties LATA konferencei, kur kā reizi runās par atvērtā koda risinājumiem. http://lata.org.lv/?page_id=54

    Kā reizi viena no prezentācijām būs par tēmu:

    “Biznesa vadības programmatūra, ERP&CRM atvērto risinājumu vidē”, Vladimirs Kuzmins, HansaWorld Latvia

    Atbildēt
  7. Kristofers

    Nācās te nupat kā reizi izstrādāt maksājumu eksportu no tā paša augstākminētā Vladimira pārstāvētā uzņēmuma produkta HansaWorld Enterprise uz eKasi (“8. Šī iespēja nav pārbaudīta – varbūt strādā.”). Strādā un nav ne vainas. Par to, vai faila formāts ir progresīvs, varētu pie kafijas parunāt, bet lielos vilcienos ir OK. 🙂

    Atbildēt
  8. neteikshu

    gerard: sanāca reiz pabūt klāt kādam pašvaldības konkursam uz kādu sistēmu (saprotamu iemeslu dēļ publiski nesaukšu visus vārdos), sanāca tā, ka uz konkursu pretendēja 2 IT firmas, kas jau darbojas šajā pašvaldībā ar savām IT sistēmām, piedāvājot Novell un Oracle risinājumus, 1 IT firma, kas gribēja ielauzties pašvaldību sfērā, piedāvāja Oracle risinājumu, kā arī viena firma, kas piedāvāja uz opensources bāzētus risinājumus. Tad nu sanāca tā, ka pirmie 3 startēja ar summām, sākot no 120k, bet pēdējais ap 50k. Diemžēl pēdējie tika atsijāti jau 1. kārtā – dokumentu pārbaudē (vēlāk gan pārsūdzēja, bet tad sūdzību atsauca – viņiem nebija taisnība), bet vinnēja 3. firma, kas uzrakstīja vislielākās cilvēkstundu darba izmaksas, bet dabūja nepieklājīgi lētas Oracle licenzes.
    Lai nu kā – nezinu, kā tas būtu strādājis ar opensource risinājumiem, bet piedāvājums opensourcei bija 2x lētāks.

    Atbildēt
  9. Persix

    Nu prieks, ka šis tas ir izsaucis interesi. To “prx”. Nu atzīšos, ka manuāli tiešām neesu lasījis, jo , manuprāt, sistēmai, kas domāta lietotājam ir jābūt “lietotājam draudzīgai” vai vismaz inutiatīvi saprotamai. Jā, protams, šīs sitēma ir domāta valsts iestādēm, bet nu jau kādu laiku ar to strādā arī biedrības, biedrības, kuras ir pieradušas pie cita veida i-banku sitēmas. Un viss šis ir tikai mans personiskais viedoklis, tas nekādā veidā neskar biedrību “Dienvidlatgales NVO atbalsta centrs”.

    Atbildēt
  10. Cipars

    Es saprotu, ka daudzi ir apsēsti ar bezmaksas produktiem, bet vai var tik vienkārši runāt par OpnS visos gadījumos. No pieredzes varu teikt, ka pārsvarā OpnS produktus visi izmanto nelielās sistēmās. Es pats ļoti gribētu redzēt, kā kāda OpnS datubāze turētos sistēmā, kurā ik gadu rodas virs 10milj ieraksti un tiek darbināti pārskati, kuru SQL aizņem 100-300 SQL rindiņas. Un nemaz nesakiet, ka MySQL 5 to pavelk! Kompānija, kurā es strādāju, regulāri izmanto OpnS produktus (Postgres, MySQL), bet ir skaidri zināmas sistēmas, kurās ir jābūt 1) garantijai, ka viss strādās’, kā uzrakstīts 2) pārbaudītam risinājumam, kāds var dot atsauksmi 3) atbalstam (supportam), kāds risinās tavu problēmu 4) augstai veiktspējai un stabilitātei 5) mērogojamībai. Esmu pārliecināts 99% OpnS fanātu nezina, kas ir augsta veiktspēja. Tas nav Web shops ar CMS! Vai DB ar 10-100 lietoājiem. eKasē vien palaižot algu izmaksu importu 1000 darbiniekiem, tiek izpildītas ap 20000 komplicētām transakcijām pāris minūtēs. Ka snotiek ja vienlaicīgi palaiž 2 iestādes tādus importus… Tā ka katram produktam ir sava niša un pielietojums. Btw, StarOfiss rullē! 🙂

    Atbildēt
  11. Iciks

    Cipar, es nesapratu, kas tur tik liels tajā importā? 100-150 komplicētas transakcijas sekundē? Vistipiskākā problēma, ka cilvēki nemāk optimizēti uzrakstīt DB appu, lai tā ātri strādātu. Piemēri:

    * Vienā valsts iestādē Oracle kaut kādu ikdienas jobu grieza līdz pat dažām stundām. Principā sāk traucēt darbam. To pašu MS SQL (cita firma gan taisīja) izdarīja pāris minūtēs.

    * Esmu redzējis kā mājas lapā ņemot kompleksus datus no MySQL, join tika veikts iekš PHPē (viens papildus selects uz katru atgriezto rindu). Var iedomāties, cik ātri tas strādāja 🙂

    Secinājums kāds? Ne jau MS SQL ir 60 reizes ātrāks nekā Oracle, ne jau MySQL ir bremze, bet gan cilvēciņiem ir vairāk vai mazāk līkas rokas, lai kaut ko izdarītu optimāli. Atkarībā no tā, cik labi konkrētajā situācijā datubāzes izpildes plānu optimizētājs spēj nooptimizēt lietotāja vai izstrādātāja pieprasījumu, atšķiras vai neatšķiras izpildes laiks, attiecīgi arī uztvertais datubāzes “lēnums” vai “ātrums”.

    Atbildēt
  12. Iciks

    Un viens liels iemesls, kāpēc pārsvarā izvēlas komercdatubāzes (tas attiecas ne tikai uz DB), ir tas, ka par to pa galvu nesitīs – vienmēr varēs pateikt – “Es taču izvēlējos vienu no tirgus līderiem, ar supportu, ar visu, un viņi tā nolohojās, ka jau kuro dienu nevar izlabot kļūdu”.

    Atbildēt
  13. Iciks

    Latvijā vienkārši nav lielu datubāzu, salīdzinot ar pasauli. Lielākajām bankām varētu runāt vēl par kaut ko. Runājot par Cipara minēto datubāzi. 10 miljoni ieraksti gadā? Vispār pupu mizas. Ja tas būtu apjoms vienā dienā, tad es vēl saprastu. Pieprasījums 100-300 SQL rindiņas? Varētu vēl indeksus no tabulām nomest, tad arī komercdatubāzes varēu nepavilkt 🙂 Kā jau rakstīju, visticamāk problēma ir nemācēšanā darbu sadalīt normālos soļos, vai neoptimāla datubāzes shēma, varbūt kāds hints palīdzētu. Protams, valsts iestādei šādā gadījumā vieglāk ir pārmaksāt daždesmit tūkstošu, iegādāties krutos dzelžus un Oracle, nevis piespiest izstrādātāju izstrādāt normālu produktu.

    Atbildēt
  14. zz

    btw, autora norādītais links uz VISR ir nepareizs un attiecas uz citu sistēmu.
    Info par ekasi ir šeit:
    https://www.visr.eps.gov.lv/visr/default.aspx?action=2&rid=13

    Atbildēt
  15. CooLynX Raksta autors

    zz, paldies par informāciju!

    Vai no tā arī izriet, ka visi pārējie skaitļi, kas attiecās uz pagājušo, šo un nākamajos gados plānotiem izdevumiem, arī ir paredzēti kādai citai eKases sistēmai?

    Atbildēt
  16. prx

    to CooLynX

    Es par šo sistēmu zinu pietiekami daudz. Kaut vai to ka datu apstrādes ātrumā ar to nevar konkurēt neviena ibanka, tās dienas apstradāto transakciju skaits pārsniedz 100 k., t.i. ~ 30 maksājumi/sek.

    To koko
    ierakstu skaits gadā jau pārsniedz 12 miljonus… parēķini pats.

    To persiks
    ekasi nevar salīdzināt ar ibankam, jo tai atbilstoši budžeta uzskaites specifikai ir savas īpatnības un šīsistēma apmierina gan mazu NVO prasības, gan lielu daudzu mega klientu prasības.

    http://www.vsaa.lv/vsaa/content/?lng=lv&id=2750&cat=2449

    Atbildēt
  17. kgb

    To prx:
    Tu putrojies savos ciparos. 100’000 transakcijas dienā nu nekādi nav 30 maksājumi sekundē. Ja vien Tavai iestādei nav viena darba stunda dienā..

    100’000+ tranzakcijas dienā * 250 darba dienas = 25’000’000+ transakcijas gadā.. Kā tad tur sanāk tikai 12 miljoni ierakstu? 😉

    Atbildēt
  18. Persix

    To prx
    Cik noprotu tu esi viens no šis sistēmas uzturētājiem vai vismaz darbinieks ar augstu pieejas līmeni. Tātad pirmais, parasti bankas rūpējas par saviem klientiem, tu jau otrajā komentārā parādīji savu attieksmi pret klientiem, izpaužot klienta datus.
    otrs, jā sistēma mani apmierina, bet tikai un vienīgi apmierina, darbs ar to man sagādā grūtības, kautgan neesu nekāds iesācējs IT lietās utt. Vēl šais sitēmai ir nepieciešami diezgan daudz uzlabojumi. Viens no tiem ir minams arī kodējums, kad saglabā pārskatus RTF, tad latviešu mīkstinājuma zīmes netiek atpazītas (seit es neatminos, vai palīdzēja tas, ka nomaini pārlūkā lapas kodējumu).
    Un trešais, kritika nav jāuztver ar dakšām rokās!!! (один удар четыре дырки ). Kritika ļauj mums kļut vēl labākiem, ko arī novēlu eKasei.

    Atbildēt
  19. BigUgga

    Ierakstu skaits nav nekāda mērvienība. Piemēram: ir 100% uz opensource bāzēta DB, kur mēnesī, rupji rēķinot, ir ienāk aptuveni 40milj ierakstu, vidējais par diennakti sanāk 15ieraksti/sec (dienas laikā, protams, vairāk). Ar tiem ierakstiem nepārtraukti arī tiek kaut kas darīts, ne tikai glabāts. Iet tas uz pavisam necilas kastes ar 1gb ram. Mērvienība, kā jau daži te minēja, ir roku līkumos – pat pašas vienkāršākās lietas var salīkumot neatlokamos mezglos i uz Oracle i uz MSSQL i uz MySQL. Risināt to īslaicīgi var, protams, sagāžot $ dzelžos.

    Atbildēt
  20. ZBH

    tikai, cik iru dzirdeejs atsuxmes un arri dabaa vienreiz apstiijies, no riitiem iebremzee nejeegaa, vai pat vispaar taut tur nevar ielogoties. atlausos 1x mineet – tautai vis DB iraid uz vien zajebravo krut RAID masiiv.

    Atbildēt
  21. one

    Vienā komentārā bija minēts, ka Oracle datu bāze esot lēnāka par MSSQL, par piemēru minot kaut kādu procesu, kurš gāja 6h. Atvainojiet, bet pēc tā vērtēt DBMS veiktspēju var tikai pilnīgs āmurs, kuram vispār nav saprotami datu bāžu pārvaldības sistēmas koncepti. Ja Oracle datu bāzes struktūru plāno web programmētāji ar līkām rokām un bez smadzenēm, kuri māk tikai SELECT, INSERT, UPDATE un DELETE, tad arī normāli noindeksēta MySQL bāze būs ātrāka par Oracle. Esmu redzējis tādus brīnumus, ko it kā “baigi krutie” IT džeki ir sarakstījuši PLSQL kodā, ka nav brīnums, ka tas viss strādā, kā piektajā gadā. Pats ar Oracle un PLSQL strādāju ikdienā un, manuprāt, tā ir labākā DBMS, kāda ir. Kaut kāds MySQL, PostgreSQL un MSSQL vēl ir bērnu autiņos salīdzinājumā ar Oracle. Protams, viss kārtējo reizi ir atkarīgs no cilvēkiem, kas to visu ceļ augšā.

    Atbildēt
  22. Iciks

    one, tas laikam bija par manu komentāru 🙂 Iesaku citreiz, nevis uzreiz akli mesties aizstāvēt sirdij tuvu lietu (šajā gadījumā Oracle), bet gan izlasīt komentāru līdz galam, it sevišķi secinājumus 🙂 Es tieši rakstīju, ka visu galvenokārt izsaka izstrādātāju roku taisnums vai līkums, nevis pati DBMS

    Atbildēt

Ieraksti komentāru

Tava e-pasta adrese netiks publicēta. Obligātie lauki ir atzīmēti kā *