Moi
Olen pyrkinyt omassa projektissa jakamaan kaiken usein käytetyn datan omiin tauluihin, jotta ei tulisi turhaa toistoa. Esimerkiksi jos taulussa "autot" on auton merkki, olen tehnyt erillisen taulun "auton_merkit" jne.
Kannattaako näin tehdä aina, vaikka kyseessä olisi lyhytkin tiedonpätkä?
Tarkoitus on tehdä taulu, jossa on eräitä arvoja ja niiden yksiköt, jotka ovat luokkaa "h", "tunti", "vuosi", "km". Elikkä käyttäjä päättää mutta pääasiassa tosi lyhyitä merkkijonoja. Kannattaako siis tehdä taulu jossa on nämä yksiköt erikseen, vai laitanko suosiolla jokaiselle riville sen VARCHAR-tyyppisenä?
Kiitos!
Tee oma taulu, jos haluat, että yksiköt on kirjoitettu aina oikein (esim. "vuosi" eikä "(v)" tai "vuotta") ja että niiden perusteella voi hakea tietokannasta tietoa (esim. vain vuosina ilmaistut arvot). Voit laittaa tauluun tarvittaessa myös taivutusmuodot ja lyhenteet ja yläkäsitteen mitattavalle suureelle (esim. "aika"). Erillinen taulu toimii järkevästi vain silloin, kun käyttäjä pakotetaan valitsemaan yksikkö valmiista listasta; muuten erillinen taulu menee täysin hukkaan.
Jos yksiköllä ei ole ohjelmassa loogista merkitystä ja käyttäjä saa joka tapauksessa syöttää sinne mitä tahansa kissoja ja koiria, sen voi hyvin laittaa tekstinä arvon perään. Silloin pitää lähteä oletuksesta, että jokaisella rivillä voi olla erilainen ja mahdollisesti väärin kirjoitettu yksikkö, eikä yksiköiden perusteella voi tehdä luotettavia hakuja.
Itse työstin työssäni erästä softaa, jossa voidaan lisätä useita erilaisia päiväkirjamerkintöjä ja noihin päiväkirjamerkintöihin täytyi pystyä lisäämään erilaisista listoista asioita esim. alue piti valita alue-listasta jne... Totesin heti jo alussa, että erilaisia listattavia asioita oli niin paljon, ettei olisi mitään järkeä luoda jokaiselle omaa taulua ja kaikkea siihen liittyvä käsittelykoodia, uusien asioiden lisäämistä listaan, kaikkein asioiden listaaminen yms... Tekemäni havainto liittyi siihen, että oikeastaan ydinasia ei tässä ollut niinkään ne listattavat asiat - koska ne ovat pelkästään dataa - vaan nimenomaan tuo listatoteutus. Teinkin siis geeneerisen listatoteutuksen, jonka avulla voidaan luoda hierarkisia listoja ja lisätä niihin juuri sitä dataa, mitä milloinkin pitää. Listat siis muodostivat oman domainin ja vastaavasti ne listattavat asiat olivat osa erityyppisiä päiväkirjamerkintöjä. Niinpä kopioin listasta datan suoraan päiväkirjamerkintä-riviin ja näin taulujen välille ei muodostu viite-eheyttä. Toisaalta viite-eheys ei ole tässä edes kovin toivottu ominaisuus, koska listoista saatetaan haluta poistaa asioita, mutta historian kannalta on olennaista, että se jää itse merkintään talteen.
Toivottavasti tämä käytännön skenaario yhtään auttoi asian pohtimisessa.
Triton kirjoitti:
Totesin heti jo alussa, että erilaisia listattavia asioita oli niin paljon, ettei olisi mitään järkeä luoda jokaiselle omaa taulua ja kaikkea siihen liittyvä käsittelykoodia
Ei tietenkään ole järkeä tehdä omaa taulua jokaiselle yksikölle, eikä tässä toivottavasti sitä kysytty.
Yleisesti ottaen uusi taulu on järkevä, jos halutaan 1:N-relaatio eli halutaan A-taulun useammalle riville täsmälleen arvo B-taulusta. Toinen vaihtoehto erilliselle taululle on joskus ENUM-sarake, jos vaihtoehtoja on melko vähän eikä niitä lisätä enää ajon aikana.
Kiitoksia vastauksista. En valitettavasti aivan ymmärtänyt Tritonin vastausta, itselläni ei ole tietotekniikan koulutusta joten termit menevät hieman ohitse.
Päädyin nyt lopulta siihen, että tein oman taulun yksiköille. Siellä rivillä on yksikkö, esimerkiksi "tunti", sekä ENUMina että onko kyseessä aika, etäisyys vai mikä.
Toivotaan että homma toimii fiksusti näin, ehkä hieman saivartelua tarkentua pikkuasioihin mutta kova hinku olisi tehdä asiat "oiken".
Triton kirjoitti:
Toisaalta viite-eheys ei ole tässä edes kovin toivottu ominaisuus, koska listoista saatetaan haluta poistaa asioita, mutta historian kannalta on olennaista, että se jää itse merkintään talteen.
Yleensä noissa ratkaisuissa (kun tehdään myös se viite) laitetaankin sen vuoksi tauluun flagi "poistettu" eikä oikeasti poisteta sieltä rivejä, jotka ovat käytössä.
Grez kirjoitti:
(27.11.2016 12:02:00): ”– –” Yleensä noissa ratkaisuissa (kun tehdään myös...
Toki näinkin voidaan tehdä. Itse kuitenkin käytän sovelluksen käsitemallinnuksessa Evansin Domain-Driven Designin menetelmiä, jossa lähdetään nimenomaan domain edellä, ei data edellä. Minulle tietokanta on lähtökohtaisesti väline tallentaa tietoa ja teen kannan rakenteesta sellaisen, että se tukee parhaalla mahdollisella tavalla sovelluksen käsitteiden vaatimuksia - en niin, että ensin kuvaisen kannan rakenteen jollain ER-kaaviolla. Tämä nyt kuitenkin karkaa jo itse topicin aiheesta.
Lähinnä nyt ajattelin että kellekään ei jäisi käsitys että historiatieto, poistaminen ja viite-eheys olisi toisensa poissulkevia asioita.
Triton kirjoitti:
Minulle tietokanta on lähtökohtaisesti väline tallentaa tietoa ja teen kannan rakenteesta sellaisen, että se tukee parhaalla mahdollisella tavalla sovelluksen käsitteiden vaatimuksia - en niin, että ensin kuvaisen kannan rakenteen jollain ER-kaaviolla.
Mielestäni se, millaiseen tietokantaratkaisuun päädytään, ei liity käytettyihin kehitysmenetelmiin vaan henkilön omaan tietoon ja ymmärrykseen siitä, miten tietokanta toimii tehokkaasti ja miten sillä saadaan toteutettua haluttu asia. Esimerkiksi mainitsemasi DDD ei millään tavalla määrää, että tietoa pitäisi kopioida taulusta toiseen, vaan se on täysin oma ratkaisusi. Toisaalta ER-kaavion piirtäminen ei myöskään automaattisesti johda siihen, että henkilö ymmärtäisi tehdä useamman taulun.
Eli kyllä tietokannasta voi tehdä järkevän ja viite-eheän, vaikka sitä ei suunnittelisi ”jollain ER-kaaviolla”. DDD on huono tekosyy huonolle tietokannalle, aivan kuten ketterä kehitys ei ole peruste dokumentaation ja suunnitelman puuttumiselle. Asiallisten relaatioiden (ja tarvittaessa poistomerkinnän) toteuttaminen ei ole erityisesti vaikeampaa tai monimutkaisempaa kuin samanlaisen datan kopiointi moneen tauluun.
Aihe on jo aika vanha, joten et voi enää vastata siihen.