Comments on: Mapperid: milliseid on ja miks neid ei kasutata?

By: Bunter

Bunter — Wed, 02 Dec 2009 02:01:54 +0000

Kõik rakendused, millega ma töötan on “keerulisema loogikaga” ehk siis vajavad mitme tabeli seostamist. Ei ole märganud mäpperi kasutuks muutumist.

By: Gunnar

Gunnar — Thu, 19 Nov 2009 09:08:58 +0000

Enamasti on mapperitel olemas on ka custom päringute tugi, millele saab ise tagastatavad tüübid vajadusel ette öelda. NHibernate’il on lisaks oma päringute keel, mis on SQL-i sarnane ja toimib üle erinevate andmebaaside (võib muidugi leida asju, mis ühes baasis on ja teises mitte). Sellega annab ka suhteliselt palju ära teha.

Idee poolest saad teha ka read-only objektid, millele vastavad andmed saad kas view või stored procedure abil ette anda.

By: Kuido

Kuido — Thu, 19 Nov 2009 08:09:55 +0000

Kõik need mäpperid muutuvad kasutuks, kui sul on süsteemil mingi keerukam loogika, mis nõuab mitme andmetabeli andmete omavahelist loogilist seostamist ehk objektorienteeritud relatsiooniline andmebaas on surnud rakendus. Niipea, kui andmetöötlus kaldub “Batch Processingust” kõrvale on SQL SERVER surmalaps.

By: Gunnar

Gunnar — Wed, 18 Nov 2009 22:23:42 +0000

Mulle on see triggeritesse igasugu tarkuse paigaldamine jätnud koguaeg selle mulje, et mõni SQL-i tasemel n00b püüab midagi uudset, kaasaegset, tarka ja meisterlikku luua. Kindlasti on asju, mida ongi mõistlik triggeritesse paigutada, kuid et igasugu rakenduse loogika seal istuks… ei-ei-ei.

By: Bunter

Bunter — Wed, 18 Nov 2009 11:59:28 +0000

Mõnikord tuleb paraku baasist lähtuda, sest rakendust tegema hakates on baas juba olemas ja toodangus. Kuidas kellelgi need rakenduse tegemised kipuvad olema. Samas näiteks pole mul neid stored proccide wrappereid õnnestunud viimased 3-4 aastat õnneks näha. Aga kui neid veel oli, siis eriti mahedaks muutsid asja tavaliselt “parim” meetod äriloogika laiendamiseks, triggerid. Iga operatsioon oli selline pingpongipalli pesumasinasse viskamine.

By: Gunnar

Gunnar — Tue, 17 Nov 2009 23:10:10 +0000

Mapperid üldiselt peaks suutelised olema selleks, et muudatused ühe käsuga teele panna. Ma ei ole väga kindel, et nad 100% optimaalse tulemuse sinu kontekstis genereerivad, kuid flushimine on neil enamasti olemas. Jällegi asi, mida pead lihtsalt proovima ja uurima, et teada saada.

See, et andmebaas ja klientkeskkonda jooksutav arvuti teineteisest kaugel asuvad, on minu arusaama järgi hetkel-on-lihtsalt-nii juhtum (kõik teavad, et see asi peaks olema kuidagi teisiti, aga tänane lahendus on selline). Sellest, et traffic väiksem oleks, siis võib kaaluda näiteks selliseid asju:

1. Andmete puhverdamine kliendi poolel (võimalik siis, kui andmeid teises otsas iga minut ei muutu). See võib vähendada päringute mahtu oluliselt ja objektide konstrueerimine läheb ka kiiremini, sest andmed on kohapeal olemas.
2. Kui on muudatusi, mida tehakse üle suure hulga andmete ja need muudatused on ühised objektidele ja neid muudatusi saab teha andmebaasis, siis võib need muudatused viia ka stored procedure taha peitu. Sellisel juhul on üks pöördumine andmebaasi, mis need muudatused ära teeb.

Kindlasti tasub kaaluda ka teenustele üleminekut, sest võrgu kirjelduse järgi tundub hajusarhitektuuri kohalt teenuste kasutamine naturaalsem. Kui salvestamise tulemused sind kliendipoolel koheselt ei huvita, siis saad kliendi keskkonna kiiremaks tegemiseks kasutada ka teenuste meetodite asünkroonset kutsumist. Teenuste korral saad paika panna andmevahetuskanalid ja vajadusel määrata neile kompressimise ka, et paketid vähem ruumi võtaks.

Mis puutub enda kirjutatud andmekihte, siis need on jõudluse osas (kui me räägime juba tõsisest kasutajate arvust või tõsiselt mahukatest operatsioonides) paremad kui see, mis mapperid pakuvad. Vähemasti on need kiiremad mapperitest, mis reflectioni peal elavad. Sellise tulemuse võib saavutada ka nende mapperitega, mis “teisel pool” kompilaatorit midagi ei loo ja ei tekita - leidub selliseid, mis genereerivad kõik vajaliku koodi valmis enne kui projekt kokku kompileeritakse. Enamasti annab neid laiendada ja nende loodut muuta ja optimeerida vajadustele vastavalt. See on ka variant, mida annab kaaluda, kui mapperite kasutamine mõistlik tundub.

By: Leinz

Leinz — Tue, 17 Nov 2009 20:18:56 +0000

Mina kasutasin eelnevatel töökohtadel mappereid. Tunnistan ausalt üles, et nende hingeellu polnud aega ega mahti põhjalikult süveneda ning “ise tehtud, hästi tehtud” loogika järgi tegin uues kohas üksi arendades enda andmebaasikihi.
Ma tõesti ei tea, mis loogika järgi need mappereid suure hunniku uusi objekte salvestavad, aga minul juhtus selline probleem:
Minu andmebaasikiht salvestas igat objekti eraldi (transaktsioonis ikka olid). Kõik oli tore, kuni tekkis probleem, et andmebaasist füüsiliselt kaugel asuvas arvutis toimus tuhandete uute objektide salvestamine väga aeglaselt (tuhanded eraldi paketid arvuti ja andmebaasivahel läbi keerulise füüsilise võrgu).
Lahenduseks tegin järgnevat:
Kulus vist pool päeva ja objektide tuhandete objektide salvestamiseks kulus ainult kümmekond päringut - kõik objektid pandi andmebaasi pärinevuse järgi kolme massiivi (iga tabeli kohta massiiv) (update, delete ja insert massiivid), insert jagati gruppidesse (maksimaalse lubatud andmebaasi päringu parameetrite arvu tõttu) ja andmebaasi poole saadetigi kümmekond hiiglaslikku käsku.

Minu küsimus ongi, et kuidas mapperid selliseid andmebaasioperatsioone teevad ning kas nendes annab sellist salvestamise viisi määrata? Mina igatahes olin rahul, et sain 5 minutilise salvestamise 10 sekundiliseks tehtud.

Tean-tean - peaksin kasutama teenuste kihti - tegelen sellega.

By: Gunnar

Gunnar — Mon, 16 Nov 2009 15:04:19 +0000

Andmemudelist alustamine tähendab seda, et kogu rakenduse kood kirjutatakse ümber andmebaasist lähtuva loogika ja mängureeglite. Andmebaas ja objektmudel pole enamasti 1:1 kooskõlla kuigi lihtsasti viidavad kui esimene mingit spetsiifikat või nii-saab-mugavamalt-stiilis häkke sisaldab. Kõrvalekaldumine kolmandamast normaalkujust on vaid üks näide.

Osad karmid mehed kirjutavad rakenduse koodi ja tabelite vahele veel terve spetsiaalse kihi protseduure, mis omakorda maailma paremaks teevad ja väga targad on. Tihti on tegemist wrapperitega kuhu hakkab aja jooksul kuhjuma igasugust töötava koodi mõttes kõrvaltegevust ja kõrvalist loogikat. Tulemuseks jälle see, et koodi tasemel tuleb teha terve rivi mõistusele vastukäivaid häkke, et andmemudel “korrektselt” arvesse saaks võetud.

By: Bunter

Bunter — Mon, 16 Nov 2009 14:19:16 +0000

Ma olen täheldanud sarnaseid väiteid. Kui inimene on kulutanud tegelikult nädalaid ja kuid oma SQL-i oskuste lihvimiseks sinnajuurde käivate API-dega, siis tundub millegipärast see mõned tunnid kuni päev nhibernatega tohutu koorem. Programmeerijad on loogilised, eks?

Üks täiendav “ei” faktor on andmemudel, mis pole absoluutselt mäpperisõbralik. Tavaliselt tähendab see 3-ndast normaalkujust räigeid kõrvalekaldumisi, halbu võtmestrateegiaid ning kolekeerulisi seosetabeleid (haakub normaalkuju eiramisega).