Olioiden tallennus vs tietokanta

[Snufkin]

Moi!

Aloin suunnittelemaan uutta ohjelmaa, joka olisi eräänlainen tietokortisto. Siinä siis käyttäjä syöttää ohjelmaan tietoa, ja sitten kykenee sitä myöhemmin hakemaan. Tietokorttien (<1000kpl) lisäksi ohjelmaan tulee eräänalainen luokitus, jolla samaan aihepiiriin kuuluvia kortteja voi koota yhteen. Eli toiminta melko simppeliä.

Nyt sitten seuraava askel olisi pohtia ohjelman rakennetta, missä homma hieman jumittaa. Tekisin nuo kortit mielellään olioina, mutta tiedon tallennuksen haluaisin hoitaa sqlite-tietokannalla. Ja tässä törmään ongelmaan, että onko mielekästä ylipäätään käyttää olioita, jos tarvittava tieto on jo jäsenneltynä tietokannassa?

Eli olisiko tällaisessa tapauksessa hyvä tapa käytää ihan perinteistä proseduraalista rakennetta ja siitä suoraan hakuja ja tallennuksia tietokantaan?

Jos taas päädyn olio-rakenteeseen, niin tiedosto olisi kai oikeampi tallennusmuoto. Tällöin tosin kaikki tieto pitää ladata käyttömuistiin ennen ohjelman käyttöä. Tietokantamallilla käyttömuistia tarvitaan paljon vähemmän.

Kyseessä on siis myös ohjelmoinnin harjoitustyö, jolloin ei riitä pelkkä toimivuus, vaan käytetyt valinnat pitää kyetä perustelemaan arviojalle. Ohjelmointikielenä on Python ja graafinen asu tehdään Tkinterillä.

Mielipiteitä tällaiseen ongelmaan?

[nm]

Nyt sitten seuraava askel olisi pohtia ohjelman rakennetta, missä homma hieman jumittaa. Tekisin nuo kortit mielellään olioina, mutta tiedon tallennuksen haluaisin hoitaa sqlite-tietokannalla. Ja tässä törmään ongelmaan, että onko mielekästä ylipäätään käyttää olioita, jos tarvittava tieto on jo jäsenneltynä tietokannassa?

Usein on mielekästä käyttää olioita koodissa ja varastoida ne relaatiotietokantaan. Tekninen termi tälle rajapinnalle on Object-Relational Mapping (ORM). Useimmille ohjelmointikielille on saatavilla kattavat valmiit kirjastot, joita sovelluksissa voi hyödyntää sen sijaan, että koodaisi rajapinnan itse.

Pythonin tapauksessa voisin suositella SQLAlchemyä ja ehkä sen päälle vielä SQLModelia, joka tarjoaa Pydantic-pohjaisen tietotyyppien validoinnin.

Linkit ORM-dokumentaatioon:
https://docs.sqlalchemy.org/en/20/orm/
https://sqlmodel.tiangolo.com/db-to-code/

[Snufkin]

Nyt sitten seuraava askel olisi pohtia ohjelman rakennetta, missä homma hieman jumittaa. Tekisin nuo kortit mielellään olioina, mutta tiedon tallennuksen haluaisin hoitaa sqlite-tietokannalla. Ja tässä törmään ongelmaan, että onko mielekästä ylipäätään käyttää olioita, jos tarvittava tieto on jo jäsenneltynä tietokannassa?

Usein on mielekästä käyttää olioita koodissa ja varastoida ne relaatiotietokantaan. Tekninen termi tälle rajapinnalle on Object-Relational Mapping (ORM). Useimmille ohjelmointikielille on saatavilla kattavat valmiit kirjastot, joita sovelluksissa voi hyödyntää sen sijaan, että koodaisi rajapinnan itse.

Joo, törmäsin tähän, kun asiasta googlettelin.

Mutta en ihan ymmärrätuota logiikkaa. Eikö oliot pidä olla kaikki luotuna käyttömuistiin, jotta niitä voi käyttää? Eli tällöin tuo tietokanta toimii ikään kuin monimutkainen tiedosto. Saman saisi aikaan vaikka json-tiedostolla. 

Vai onko tuossa idea, että noita olioita ladataan tarpeen mukaan, mitä käsiteellään? Eli tuollaisen laajemman ohjelman logiikkaa?

[Snufkin]

Sitten on vielä tällainenkin vaihtoehto, eli käyttää suoraan olio-tietokantaa. Vaatisi taas enemmän perehtymistä, mutta tuossa voinee oliot tallentaa suoraan niille sovitettun tietokantaan.

https://en.wikipedia.org/wiki/Object_database
https://en.wikipedia.org/wiki/Zope_Object_Database (pythonille)

[nm]

JSON vaatii koko tiedoston lataamisen ja parsimisen, jos haluat lukea tiedostosta edes yhden arvon. Vastaavasti tallennettaessa koko tiedosto pitää serialisoida uudelleen. Lisäksi tekstimuotoinen formaatti ei ole erityisen tehokas. SQL-tietokanta välttää nämä ongelmat, eikä kyselyn mäppäys olioksi aiheuta merkittävää lisäkuormitusta.

Serialisointi JSON-tiedostoihin voi olla varteenotettava vaihtoehto, jos sisältö pitää olla ihmisen luettavassa muodossa, eli sitä pitää päästä lukemaan ja muokkaamaan tekstieditorilla. Muuten Sqlite on useita kertaluokkia tehokkaampi ja siistimpi ratkaisu.

ORMissa siis muunnetaan SQL-tietokannan kyselyn tulos oliomalliin, joka sijaitsee vain muistissa. Sitten voit muokata olion muuttujien arvoja ja lopuksi pyytä ORMia tallentamaan sen uudelleen tietokantaan. Fiksuimmat toteutukset saattavat tallentaa vain muuttuneet arvot, mutta tällaisia yksityiskohtia ei yleensä tarvitse miettiä, ellei järjestelmä käsittele oikeasti suuria datamääriä.

[Snufkin]

Hmm...tuon tietokannan etuna olisi kieltämättä myös se, että ei tarvitse kaikki olioita ladata kerralla muistiin, vaan tarpeen mukaan.

Mulla tämä työ on niin simppeli, että voisi koittaa tehdä itse oman ORMin, eli funktiot, joilla saa olion tietokantaan ja sieltä pois. Voisi olla hyvää oppia aiheesta ja sql:n kerausta.

Ihmisluettavuuden takia ohjelmaan voisi lisätä jokun export-option, joka tulostaa tiedot vaikka ihan tekstitiedostoon. Niiden sörkkiminen suoraan tiedoston (json) ei kuulosta kyllä hyvältä idealta.

[Jere Sumell]

Itse olen käyttänyt seuraavaa toimintamallia olio->relaatiotietokanta sql-kantoihin tuppaamisen osalta.

Tietokanta
1. Tietokannan määrittely ja ohjelmointi-> .sql -tiedostoon koodi
2. kannan tuppaaminen palvelimelle.

Datan tietotyyppien ohjelmointi
1. Tietotyyppien määrittely
2. Ilmentymien luonti
3. Ilmentymistä datan ulostulo JSON -muodossa.

JSON-datan tuppaaminen palvelimella sijaitsevaan tyhjään sinne tupattuun tietokantaan.

Jokseenkin tuo on mielestäni selkeä malli perusteiltaan, mihin olen itse mieltynyt toimivana ratkaisuna.

[_Pete_]

Mutta en ihan ymmärrätuota logiikkaa. Eikö oliot pidä olla kaikki luotuna käyttömuistiin, jotta niitä voi käyttää? Eli tällöin tuo tietokanta toimii ikään kuin monimutkainen tiedosto. Saman saisi aikaan vaikka json-tiedostolla. 

Vai onko tuossa idea, että noita olioita ladataan tarpeen mukaan, mitä käsiteellään? Eli tuollaisen laajemman ohjelman logiikkaa?

Yhden kortin tiedot pitää joka tapauksessa olla ladattu muistiin muodossa tai toisessa jotta sitä voi käsitellä tai näyttää ohjelmassa.

Se onko tieto oliossa vai tietueessa (struct tms mikä nyt onkaan python kielessä vasrtaava) ei ole oleellista.