Ma olen näinud ära mõned suuremad süsteemid, kus kogu äriloogika oli protseduuridesse viidud. Algul tundus kõik koodi tasemel tore – kutsume protseduure koos parameetritega ja need siis tegutsevad ja teevad musta töö ära. Peale esimest kuud aega oli mu kopp-level suht kõrge. Koodihunnik, mis protseduuride vahet andmeid liigutas, kasvas koguaeg, protseduure tekkis ja tekkis ja tekkis ning nende haldamisele kuluv aeg kasvas ka seejuures. Samas selliseid elementaarsed asjad nagu lazy loading, per-request cache, per-application cache ja objektide kasutamine jäid ära.

Kõige rajumaks läks lugu siis, kui protseduurid hakkasid ka keerukamaks muutuma. Osa äriloogikat toimis nii või teisiti lähtekoodi tasemel. Ülejäänu istus andmebaasis. See tähendas kokku seda, et kui kuskil tekkis viga, siis debugimisele kuluv ajakulu oli suurem kui tavaliselt – tuli ju vigu taga ajada nii koodi kui ka andmebaasi tasemel.

Kõige loetavam ja seega paremini hallatav kood on see, mis kasutab äriobjekte. Sellisest koodist on võimalik lugeda täpselt välja, mis juhtub ja miks juhtub ja kuidas juhtub. ADO.NET objektid, ADODB objektid jne seda võimalust ei paku. Kui tegemist on suurema süsteemiga, mida keegi mõnikord edasi tahab arendada ja hallata kavatseb, siis on OO kõige kindlam minek ja mapper toob endaga lihtsalt kaasa võimsa objektide haldamise runtime’i, mille loomine igas arenduses oleks suhteliselt mõttetu tegevus.

Samas ma näen probleeme andmebaasiprotseduuridega. Tegemist on ikkagi protseduraalse maailmaga ja koodi taaskasutus on piiratud. Klasse ja pärimist pole ning seetõttu ei saa edevamaid programmeerimisvõtteid kasutada. Loodetavasti on objekt-orienteeritud kood ka loetavam kui SQL.

Arvatavasti lasen programmeerijatel teha mis tahavad. Kui nad nii on harjunud tegema, siis ilmselt teevad nad seda kõige efektiivsemalt. Õnneks on tegemist intraneti saidiga, kasutajaid kuskil paarikümne ringis, nii et performance pole oletatavasti probleemiks. Mingi avaliku veebisaidi puhul kaaluksin viis korda üle.

Mis puutub baasi kasutamist, siis selles osas vaevalt, et midagi enne paremaks läheb, kui CAML-ist saab päringute keel. Hetkel on see pigem nagu tore ja töötav demo kui tõsiselt võetav päringukeel. Reaalelulistele vajadustele vastavaid päringuid ei lase see tihtipeale teha ja nii arendajad kirjutavadki vastu SPListItemCollectionit for tsükleid ning teevad sel teel koodi tasemel päringu. Mina olen sellistes kohtades alati öelnud kliendile, et sellist asja ei saa teha. Kuigi täna on vastavas listis võib-olla käputäis ridu, ei tähenda see seda, et seal homme suurusjärgu või paari jagu enam neid poleks.