Mikä on WikiWiki?
nettipäiväkirja
koko wiki (etsi)
viime muutokset
(nettipäiväkirja 22.10.2015) Olen aina inhonnut ORMeja (object-relational mapper). TL;DR: voit käyttää ORMia tietojen päivittämiseen mutta älä käytä sitä kyselyihin.
Olen kyllä samaa mieltä siitä, että jonkinlaista abstraktiota tarvitaan SQL-tietokantojen tietotyyppien muuttamiseksi ohjelmointikielen natiiveiksi tietotyypeiksi ja takaisin - esimerkiksi PHP:n lähtökohta, että kaikki tietokannasta tuleva on vain erilaisia merkkijonoja, ei ole kestävä. Mutta kunnollinen SQL-tietokantojen API määrittää tällaiset mäppäykset, ks. esim. http://initd.org/psycopg/docs/usage.html#adaptation-of-python-values-to-sql-types
Olen myös samaa mieltä, että jonkinlainen helponnus on syytä olla siihenkin, että esimerkiksi rivin lisääminen ja päivittäminen tietokannassa ovat oikeastaan aika samanlaisia operaatioita ja rivin ID:n perusteella pystyy vielä automaattisesti päättelemään, kummasta on kyse. On pöhköä kirjoittaa aina erikseen koodia INSERTien ja vastaavien UPDATEjen tekemiseen. Tämän ORM hoitaa hyvin.
Mutta on täysin järjetöntä muuttaa SQL:n SELECT-lausekkeita, jotka ovat hyvin suunniteltu (vaikkakin historiallisen painolastin kuormittama) funktionaalinen ohjelmointikieli, joksikin oman ohjelmointikielen natiivirakenteiksi. Sen seurauksena joutuu vain opettelemaan yhden DSL:n lisää, eikä oikeasti pääse SQL:stä eroon, koska joka kerta, kun ORM toimii jotenkin väärin, joutuu tarkistamaan automaattigeneroidusta SQL:stä, mikä on vialla.
SELECTin abstrahointi pois ei aiheuta kuitenkaan vain ohjelmoijalle lisävaivaa, vaan vaikeasti havaittavia ja korjattavia suorituskykyongelmia. SQL:n pointti on se, että kysyt tietokannalta juuri ne tiedot, joita haluat, eli siirrät tiedon prosessoinnista mahdollisimman paljon tietokannan puolelle. Ei ole esimerkiksi järkeä hakea tietokannasta ryhmää, sitten sen kaikkia jäseniä, ja sitten laskea keskiarvo jäsenten i'istä, kun saman voi kysyä tietokannalta suoraan. ORM tekee helvetin vaikeaksi kertoa, mikä on se tieto, jonka tietokannasta haluaa. ORM-kirjastoissa on erilaisia "join-strategioita", jotka kertovat, miten tiedot haetaan tietokannasta olioihin. Niitäkään ei voi soveltaa aggregaattien laskemiseen tai mihinkään järkevään.
Törmään säännöllisesti ORMia käyttäviin softiin, jotka osoittautuvat järjettömän hitaiksi heti, kun jotain tiettyä tietotyyppiä on tarpeeksi monta - siis vaikkapa 300 riviä tietyssä taulussa. Tyypillisesti syy on se, että ORM suorittaa automaagisesti jonkin helvetin monimutkaisen yhdistelmäkyselyn jokaista tuon taulun riviä kohti, koska sovellus käy niitä rivejä läpi olioina ja linkkien laiska haku tietokannasta tuottaa kyselyn kerrallaan. Törmäsin nyt tämän saman ongelman kuvaukseen vaihteeksi Javasta kertovalla sivulla; maailma muuttuu: http://blog.paralleluniverse.co/2014/05/15/modern-java-pt3/#database-access