[geek]

Ütleme, et on tabel asukoht. Millel on väljad postikood, linn, tänav.
Tabelis on andmed kujul:
Linn, Postikoodi algus, Tänav.
Tallinn, 43, Lasnamäe tänavad
Tallinn, 431, Kure
Tallinn, 432, Kana
Tallinn, 44, Mustamäe tänavad
Tallinn, 443, Tuvi
Tartu, 55
Narva, 99

Ja mul on vaja teha query. Mis tagastab mulle täieliku postikoodi järgi kõik linna tänavad, mis sobivad postikoodi mustriga. Posti koodi anna ette kujul näiteks 43135

Query mis ma ise mõtlesin, aga nii kahjuks ei toimi.

[napoleon]

Kui muster on 123, siis puhas SQL oleks selline:

[XD]

Kui postikoodid on ilusti hierarhias, võta sisendis olevast postikoodist substring, kas ainult esimene või esimesed kaks numbrit.

[iFlop]

napoleon, küsimus oli ju ikkagi selles, et postikoodi osad on baasis erineva pikkusega? See pole väga ilus, aga peaks töötama:

[napoleon]

Sry, kiiruga lugedes ei vaadanud, et teistpidi match tuleb teha.
Kui muster on alati sama pikk või pikem, on ilusam nii:

[Fukiku]

napoleoni pakutud lahendustel on üks häda, mis hakkab vähegi suurema andmemahu puhul kohe valusalt lööma - substring või concat operatsioon tehakse iga päringu korral iga tabelis leiduva rea jaoks uuesti. See ei ole kindlasti mõistlik jõudluse mõttes. Lahenduseks oleks funktsionaalne indeks, kus oleks vastav väärtus juba eelnevalt välja arvutatud iga rea kohta, aga paraku MySQL ei paista sellist võimalust omavat kiire guugeldamise põhjal. Asenduslahenduseks pakutakse peamiselt reaalsete veergude lisamist tabelisse, kuhu insert ja/või update triggeritega õiged väärtused välja arvutatakse, et nende järgi pärast pärida.

Keerulisem lahendus oleks muidugi mingi vinge seostabelite struktuur aretada, kus iga indeks oma prefiksitega välisvõtmete kaudus seotud on.. aga tea, kas tasub.. selle võrgustiku korrektne hoidmine nõuab ka omaette põhjalikku läbimõtlemist ilmselt.

PS. Kuidas andmebaasinduses on korrektne tõlkida eesti keelde terminit trigger? Tahtsin kirjutada eestikeelset teksti, aga mitte ei suutnud hoobilt tõlget leiutada. Päästik nagu ei kõla igatahes.

[i485729]

[serk]

päästikprotsess, lameandebaasi, lausendid, adapteerima? Küll on palju uhkeid sõnu aga programmeerimis maailmas on de facto standard inglise keel. Minu keel ei suuda küll triggeri asemel välja öelda päästikprotsess - kõlab ikka täieliku pornograafiana.

Ma nüüd laksan risti vastupidi, progrejate geto keeles:
Stored proccide/funktsioonide kasutamine sõltub DBst ning businessi soovidest/rahast. Oluliselt kirvem/raskem on ehitada ja hallata rakendust, mille äriloogika on viidud DBsse- inimene, kes tuleb välja selliste küsimustega ei saagi sellega normaalselt hakkama ja pole suurt mõtet rääkida sügavast või laiast tabelist või standardsest relatsioonilisest mudelist vs hierarhiline mudel ja plussidest ja miinustest mis sellega kaasnevad. Indexi tüüpidest ei saa enamjaolt aru ka elukutselised kutid. Pigem kirjutada oma sql laused rakenduses kui teha baasi stored proc ja siis seda sealt omakorda SQList välja kutsuda ja imestada miks asjad ei performi.

Kui vaatan esimese postituse näidet ja soovi ning probleemiks saavad suured andmemahud, siis saad väga lihtsalt partitsioneerida. Tekita postiindexi tabelisse uus veerg kus hoiad esimest numbrit, kokku tekib sul 9 partitsiooni ja probleem peaks lahenema mingis mahus. Täitsa ekstreemsuste korral on ka võimalus viia index andmebaasist välja ning teostada otsingud eraldi masinas, mis juba cachib ning teeb otsinguid puhtalt mälus ning mille puhul DB poole pöördutakse ainult primary keyde järgi. Lisaks kui mälu rõvedalt palju üle, võid ka terve tabeli mällu lugeda - jookseb nii et kole kohe. MySQL pakub ka selleks võimalusi.

Soovin edu!

[YberCyrus]

Nõustun serki statemendiga, et äriloogika viimine SQLi pole väga hea idee. Sellist lähenemist võib näha finants sektoris (tõenäoliselt vanemad rakendused) kus äriloogika muutub päevast päeva ja varem oli muutuste sisse viimine tülikam. Procide updatemine on märksa lihtsam kui hunnikute serverite redeploymine.

Tänapäeval pole see väga keeruline võttes arvesse .NETi/Java redeployment võimalusi. Javas on täitsa võimalik kasutada hot deplymenti OSGi standardis või siis kasutada kaasmaalaste toodet LiveRebel. Isiklikult ma PHPd mission critical rakenduste kasutamiseks ei kasutaks aga PHPs on updatede sisse viimine kõige lihtsam (ei oska argumenteerida kompileeritud PHP koodiga mida võimaldavad teatud rakendused nagu HipHop).

Rääkides natuke object relational mapperitest mis on väga populaarsed librarid DBga suhtlemiseks ja võttes esmalt ette Hibernate/NHibernate siis üks benefit selle kasutamisel on multi SQL dialecti support. Võimalik on SQLi providerit vahetada äärmiselt kergelt ja stored procide kasutamine oleks korralik counter argument kuna need tuleks tõenäoliselt käsitsi ümber portida. .NETi Entity Framework by default muid providereid ei toeta peale MSSQLi aga kui SQL provideril on ADO.NET support olema siis takistust ei peaks tekkima. Hibernate/NHibernatel on second level cache mis võimaldab andmebaasi hammerdamist kõvasti leevendada, stored procide kasutamine tõenäoliselt nulliks selle võimaluse.

Eesti keel paneb isegi mõne kogenuma venna pead kratsima kui ülikoolist tulnud vend üritab eesti keeles purssida IT termineid.

Ma pole ise kunagi äriloogikat vägistanud stored procidesse ja pole ka ühtegi enterprise rakendust siiamaani näinud mis seda teeks, seega minu arvamus stored procidest on puht teoreetiline ja vabandan faktivigade pärast mis mu jutust välja võivad paista.

[serk]

[napoleon]

[i485729]

[YberCyrus]

[serk]

"Ja ega väga ei saa oodata arendaja poolt sügavaid DBA teadmisi ja pealegi ORMi kasutamine on kiirem ja vajab vähem koodi kirjutamist kui käsitsi queryde kirjutamist ja nende executemist baasi vastu. "

Nagu ennist ütlesin, et see tüüp vastus Java arendajate poolt.
Tõstavad arendajate produktiivsust? Suhteline. Neid inimesi kes näiteks Hibernatei tõesti hästi tunnevad, on ikka väga vähe. Varem või hiljem juhtub mingi jama kas transkatsioonidega või performanciga ja sinna hakatakse päris tõsiselt aega ja ressurssi toppima. Lisaks on Hibernateis vähegi keerukamat äriloogikat täiesti võimatu rakendada. Mul on läbi ajaloo kümneid ja kümneid programme, kus algselt on tehtud ilus domeeni mudel javasse ja ühel hetkel kui asi on üle käte läinud, loodud kõrvale NativeSQLid. Ehk kokku on keeratud täiesti mõttetu kompott. Ühelt poolt on mega mölakas entity mapping, mida üks kurat ei julge enam muuta ja teisalt on kõrval NativeSQLide laadung. Kuna ma tean milleks on tänapäeva andmebaasid võimelised, siis seetõttu olen ka väga kriitiline.

SOA on tore ja kahe käega poolt. Tubli!

[i485729]

[Fukiku]

Viskaks oma kaks senti ka siia üldteoreetilisse arutellu, mille võiks ilmselt praegu juba eraldi alateemasse tõsta võrreldes esialgse küsimusega.

Ilmselt ei saa mind lugeda küll mingis tohutult kogenud veebiarendajaks ning samuti tuleb tõdeda mu erialase hariduse puudulikkust (kuigi natuke sai ikka akadeemilist IT-d ka nuusutatud oma stuudiumi jooksul vabaainete formaadis).

Enda arvamused teemal "äriloogika baasis" jõudsid igatahes selle nelja aasta jooksul, mil ma ühes Eesti suuremas tarkvarafirmas rügasin, seinast seina ära käia.. Samuti võis näha suhtumise muutusi ajas ja erinevate meeskondade vahel, kus oli võimalus töötada. Praegu mulle igatahes tundub selgelt, et tihti on äriloogika baasi tõstmine täiesti õigustatud ja probleem, miks see tihti ilmselt arendajatele vastukarva on (ja ma ise olen seda ka mingitel hetkedel tundnud), on ilmselt tingitud pigem sellest, et see nõuab ühe täiendava kompetentsi suhteliselt heal tasemel valdamist lisaks oma põhikeelele. PL/SQL tõepoolest nõuab mõnevõrra teistsugust ajuehitust ja mõningast harjumist, kui aastaid on ainult Javat söögi alla ja peale toodetud.

Vastuseks siin YberCyruse väidetule võin oma kogemusest öelda, et olen vähemalt kahte Eesti mõistes väga suurt süsteemi näinud, kus arvestatav osa oluliselt äriloogikast elas Oracle otsas. Osaliselt räägiti mõlemal juhul põhjustena muuhulgas ka sellest, et kunagi ammusel aal on Oracle võlurid organisatsiooni tekkinud ja asja üles ehitanud ja nüüd läheb vanast inertsist.. (sealjuures humoreskina võib mainida, et ühes organisatsioonis oli selleks võluriks vanem naisterahvas klassikalise Eesti nimega, mida omistaks ainult sokki kuduvatele vanaemadele...) Samas ühes organisatsioonis oli selgeks plussiks sellel süsteemil ka see, et seal otsas tõesti istus kaks erinevat komplekti rakendusi, nagu ka i485729 siin välja toonud on - avalikud veebirakendused kodanikele ja majasisesed ametnikurakendused. Kogu loogika dubleerimine oleks arvatavasti küll ainult ühe suure bugirägastiku tekitanud..

Oma viimases projektis sai ka iseenda peal loomkatse tehtud poolkogemata.. Oli kaks üsna sarnase sisuga tööülesannet mul ees, kus oli vaja baasis terve hunnik seoseid ära muuta objektide küljes (allüksuse liigutamine ühe vanemüksuse alt teise alla vms.) Esimese komponendi juures hakkasin otsast pihta andma ja üritasin kogu selle keemia Javas ära teha - tõmbad objektid baasist alla, muudad asjakohased väljad ära ja salvestad uuesti. Igavene kepp ja keberniit oli, et seda tööle saada.. Teisel sarnasel komponendil mõtlesin, et prooviks PL/SQL lähenemist asjale .. kirjutasin baasi ühe protseduuri mingi kahe või kolme sisendiga, sisuks hunnik insert/update/delete kraami.. ja kõik läks märksa valutumalt. Ehk siis nagu eelpool korduvalt on mainitnud - Hibernate ja muud ORM-id on mänguprojektide jaoks täitsa head.. aga kui on vaja tõsisemaid andmeoperatsioone teha, siis lähed ikka halliks seal otsas ja hakkavad igasugu toredad asjad sulle jalga tulistama ühest ja teisest suunast.

Ja üks asi, mida ma olen õppinud armastama, on view'de kasutamine.. taaskord on märksa mõnusam kirjutada rõvedalt keerulise päringu asemel baasi poolele üks view ja Javast selle poole lihtsa "select *" päringuga pöörduda, kui sedasama päringut Javas kokku vägistada. Triggeritega ajalootabelite hoidmine jms teema on ka täitsa mõnus ja mugav.

Sai nüüd natuke laialivalguv see jutuke.. aga välja tahtis ta minust tulla.

PS. praegu ei tegele enam programmeerimisega põhitööna, aga üks väike projektike jäi jälle ette.. esimese asjana kirjutasin baasile view, millest oma andmed kätte saada, kuigi kasutatavad arendusvahendid lubasid otse baasi pealt mulle kohe ORM mappingud genereerida ja muud roosamannat.

[napoleon]

Mina pooldaks samuti võimalusel äriloogika baasis hoidmist kuigi paljud vaidelvad sellele vastu põhjendusega, et see seob rakenduse ühe konkreetse baasi külge. Samas suurtes organistatsioonides võivad põhjused miks asju üht- või teistmoodi tehakse hoopis teistsugused olla.

Spoiler

Korraldati kord katse, kus kõrgesse ruumi pandi kinni seitse ahvi. Keset lage oli riputatud kimp banaane ja nende alla treppredel. Teatud kõrgusest alates aktiveerisid trepiastmed aga lüliti, nii et kui mõni ahvidest püüdis üles ronida, pritsiti terve tuba üle jääkülma veega.
Ahvid said peagi aru, et parem on redel ja banaanid rahule jätta ja hakkasid muude asjadega tegelema.
Nüüd aga viidi üks ahvidest minema ja tema asemele toodi uus. Uustulnukas märkas kohe banaane ja tahtis neile järele minna. Teised ahvid tirisid ta redelist eemale ja klohmisid natuke, nii et uus AHV sai ka aru, et targem on banaane mitte puutuda.
Nüüd vahetati välja keegi teine. Järgmise ahviga läks samamoodi: tuli, nägi banaane, sai tappa. Tähelepanuväärne on aga see, et kõige rohkem klobis viimast ahvi eelmine uustulnukas, kes polnud üldse veega pritsida saanud!!
Nõnda vahetati järk-järgult välja kõik ahvid, kuni esialgsest seitsmest polnud enam kedagi järel. Keegi ei teadnud külmast veest midagi (pealegi oli see juba ammu välja lülitatud), aga kõik teadsid, et banaane ei tohi võtta ja kõigile uutele tehti see ka kohe selgeks.
Sellisel viisil kujunevadki välja organisatsioonikultuurid…

[neros]

Pean ka sõna sisse ütlema. Äriloogika asukoht võiks eelkõige sõltuda ikkagi rakenduse tüübist, vajaminevast funktsionaalsusest, hallatavuse nõudest ning tuhandetest teistest muutujatest. Üheselt ei saa öelda, "pane äriloogika baasi või go home". Kui kogu "loogika" on mingi keeruline formula mis pannakse 10st eri tükist vastavalt muutujale kokku ning mis ühel hetkel tahab ka baasist andmeid saada - no ei hakka ju SP'd tegema selle jaoks. Võin välja tuua ühe süsteemi mida ma aasta aega tagasi tegin, kus andmebaas hoiab ainult tulemit. Kogu loogika pannakse dünaamiliselt domeenikihis kokku vastavalt kasutaja valitud komponentidele ning seadetele. Kuna kasutajal peab olema võimalus ka valemeid muuta on the fly, siis kiiremalt ja lihtsamalt sai see tehtud CSharpCodeProvideriga kui oleks andmebaasis oleva loogikaga ettegi suutnud kujutada.

Mitte ükski asi tarkvaraarenduses ei ole must ega valge. Kõik sõltub vajaminevast lahendusest. Arendajad teevad lahendusi. Programmeerijad kirjutavad ainult koodi ja ei mõtle kuidas kõige mõttekam oleks vajadusele läheneda. Vahest on parem kui loogika istub baasis, vahest kui istub rakenduses. Ning vahetevahel juhtub ka nii, et kasutada tuleb mõlemat. Ei ole ühte ja õiget lahendust. Jah, ka harjumus tuleb mängu, aga lõpptulemuse huvides tuleb aeg-ajalt harjumustest üle vaadata ja teha nii, kuidas parem on.