Sivulla on kommenttijärjestelmä, joka toimii MySQL:llä. Systeemissä on myös käyttäjätunnukset.
Olkoon siis vaikka taulu "kommentit", jossa on jokainen kommentti omana rivinään, ja lähettäjä on tallennettu id-numerona.
Vastaavasti taulussa "userit" on jokaisen käyttäjän id-numero ja käyttäjätunnus.
Kun haluan listata kommentit, on tietenkin aiheellista näyttää myös niiden lähettäjien käyttäjänimet. Kysymykseni on siis, miten tämä olisi järkevintä tehdä? Olen keksinyt kolme vaihtoehtoa (Huom. Lauseiden teko onnistuu kyllä, niitä en pyydä tekemään):
1. Haen samalla kyselyllä kommenttidatat ja kommenttitaulun lähettäjäid:n perusteella niitä vastaavat käyttäjänimet käyttäjätaulusta
2. Haen ensin kommenttidatan yhdellä lauseella ja sitten koostan jollain PHP-skriptillä listan niistä käyttäjä-id:istä, joilta oli kommentteja haetussa kasassa. Sen jälkeen haen uudella SQL-kyselyllä listaa vastaavat käyttäjänimet käyttäjätaulusta.
3. Luon kommenttitauluun uuden sarakkeen käyttäjätunnukselle, johon siis tallennetaan myös lähettäjän tunnus aina kommentin lähetyksen yhteydessä. Kommentteja haettaessa ei käyttäjänimiä tarvitse erikseen hakea, mutta jos käyttäjä haluaa vaihtaa tunnuksensa, täytyy ajaa SQL-komento, joka käy kommenttitaulun läpi ja päivittää kaikki tarvittavat käyttäjätunnus-sarakkeet ajan tasalle.
Osaisiko joku vähän enemmän MySQL:n saloihin perehtynyt selventää, mikä näistä kolmesta tavasta olisi serveriystävällisin? (kun oletetaan, että käyttäjämäärä ja siten tehtävien hakujen määrä voisivat kasvaa suuriksikin, esimerkiksi useisiin tuhansiin päivässä)
Haluan siis nimenomaan jättää systeemiin mahdollisuuden vaihtaa käyttäjänimeä, eli käyttäjien tunnistus pelkän tunnuksen perusteella ei oikeastaan tule kyseeseen. Kiitos, jos joku osaa valaista asiaa!
Kolmas tapa on tehokkain, sillä tietoa täytyy noutaa vain kerran yhdestä taulusta. Mutta ongelmana on mainitsemasi tietojen päivitys, ja samalla tietokantaan tallennetaan samoja tietoja moneen kertaan. Siksi minä suosittelen ensimmäistä tapaa, joka on tosin hieman hitaampi, mutta ei mitenkään merkittävästi hitaampi. Silloin yksi kysely riittää ja tiedot ovat varmasti ajan tasalla.
Tuo kolmas tapa raiskaa relaatiotietokannan perusperiaatteita vaikka onkin nopein. Eli ehdottomasti tuo 1-tapa (tarkoitathan nyt hakua kahdesta taulusta simppelillä JOINilla), eikä sekään hidas/raskas ole, kunhan indeksit on kunnossa.
Relaatiotietokannan idea on mm. vähentää toistoa, se helpottaa ylläpidettävyyttä ja pitää tietokannan koon pienenä. Nopeusero hauissa on myös aivan mitätön, mikäli vain pidät ne pääavaimet indekseinä ja teet hakukyselyn käyttäen joinia. Eli ehdottomasti ensimmäinen vaihtoehto, noin se homma tehdään oikeasti isoissa tietokannoissakin (kuten Wikipediassa jne.).
ajv kirjoitti:
Tuo kolmas tapa raiskaa relaatiotietokannan perusperiaatteita
Eipäs, kannattaa lukasta vaikkapa http://www.tp.spt.fi/~salabra/ha/
Tuo usea tuhat hakua päivässä on todella vähän joten turhaan mietit sentakia serverin kuormitusta. Jotenka 1-tavalla tuo kannattaa tehdä.
Opiskelija kirjoitti:
ajv kirjoitti:
Tuo kolmas tapa raiskaa relaatiotietokannan perusperiaatteita
Eipäs, kannattaa lukasta vaikkapa http://www.tp.spt.fi/~salabra/ha/
Relaatiotietokannat/normalisointi.html kyllä nuo kaikki normaalimuodot jne... kuuluvat relaatiotietokannan perusperiaatteisiin.
Eh... en tältä istumalta jaksa tuota lukea täysin ajatuksella, mutta pikavilkaisulla ihan normalisoinnin peruskauraahan tuolla linkin takana näytti olevan.
Mutta siis edellä väittämäsi mukaan sinusta tuo on normalisointia ja relaatiotietokannan optimointia, että on käyttäjät-taulu ja sitten viestit-tauluun kuitenkin kirjoitetaan käyttäjän nimi, eikä viitettä käyttäjä-tauluun?
Linkkisi kolmannen normaalimuodon "ei näin"-esimerkissä on juuri esittämäsi 3. tietokantarakenne. Eli se on turhaa toistoa, mikä ei kuulu hyvään tietokantarakenteeseen.
ajv kirjoitti:
Eh... en tältä istumalta jaksa tuota lukea täysin ajatuksella, mutta pikavilkaisulla ihan normalisoinnin peruskauraahan tuolla linkin takana näytti olevan.
Niin aika perustietoutta tuolla oli, mutta suosittelen silti lukemaan ajatuksen kanssa koko sivun.
ajv kirjoitti:
Mutta siis edellä väittämäsi mukaan sinusta tuo on normalisointia ja relaatiotietokannan optimointia, että on käyttäjät-taulu ja sitten viestit-tauluun kuitenkin kirjoitetaan käyttäjän nimi, eikä viitettä käyttäjä-tauluun?
Luehan tarkemmin mitä kirjoitin. "kyllä nuo kaikki normaalimuodot jne... kuuluvat relaatiotietokannan perusperiaatteisiin.". En siis sanonut varsinaisesti mitään normalisoinnista, vaikka linkin urlissa niin lukee.
Väität siis, että kaikki muut kuin kolmas normaalimuoto ovat relaatiotietokannan perusperiaatteita vastaan?
Entäs sitten denormalisointi jota tuolla linkittämässäni sivussa käsiteltiin?
JTS kirjoitti:
Linkkisi kolmannen normaalimuodon "ei näin"-esimerkissä on juuri esittämäsi 3. tietokantarakenne. Eli se on turhaa toistoa, mikä ei kuulu hyvään tietokantarakenteeseen.
Ei sen toiston välttäminen ole aina hyväksi. Toki tuo kolmas normaalimuoto on usein käytetty ja koitetaan vähentää toistoa, mutta se ei tarkoita että muut normaalimuodot ovat relaatiotietokannan perusperiaatteita vastaan. Lukaseppas tuota sivua hieman lisää.
Tietenkään normaalimuodot eivät ole kiveen hakattuja sääntöjä; tietokanta kyllä toimii vaikka normaalimuodoista poiketaan. En vain näe mitään syytä vaikeuttaa ylläpidettävyyttä ja monimutkaistaa sovelluksen rakennetta, ellei sitten palvelinteho todellakin ole riittämätön normaalimuotojen mukaisen tietokantamallin ajamiseen (jolloin mielestäni oikea ratkaisu on lisätä palvelintehoja).
JTS kirjoitti:
Tietenkään normaalimuodot eivät ole kiveen hakattuja sääntöjä; tietokanta kyllä toimii vaikka normaalimuodoista poiketaan.
Juu, mutta tässä ei ollut kyse normaalimuodoista poikkeemisesta. Kyllä ensinmäinen ja toinen on myös normaalimuotoja kuten kolmas tietenkin eri säännöillä.
JTS kirjoitti:
En vain näe mitään syytä vaikeuttaa ylläpidettävyyttä ja monimutkaistaa sovelluksen rakennetta
Toki tässä tapauksessa ei noin kannata tehdä koska kyseessä on vain muutama tuhat hakua päivässä joka ei aiheuta serverille ongelmia, kuten aikasemmin totesin. Jos noin vähäisestä tulee ongelmia niin silloin kannattaa miettiä tehojen lisäämistä.
Mutta yleisesti ottaen ei se ylläpidettävyys ja sovelluksen rakenne aina monimutkaistu, usein jopa helpottuu. Tietenkin ylläpidon kanssa tulee ongelmia jos väkipakolla aletaan tekemään eri (vääriin) normaalimuotoihin jotka eivät ole käyttökelpoisia sovelluksessa jota ollaan tekemässä, kuten tuon tuossa linkittämässäni sivussa. Ylläpito vaikeutuu myös silloin jos käytetään kolmatta vaikka ensinmäinen tai toinen normaalimuoto sopisi tarkoitukseen paremmin.
JTS kirjoitti:
ellei sitten palvelinteho todellakin ole riittämätön normaalimuotojen mukaisen tietokantamallin ajamiseen (jolloin mielestäni oikea ratkaisu on lisätä palvelintehoja).
Mutta kannattaa miettiä kannattaako palvelintehojen lisäyksestä maksaa paljon jos sama asia saavutetaan denormalisoinnilla. Tämä tietenkin silloin kun puhutaan huomattavasti suuremmista kuin muutama tuhat hakua päivässä.
Opiskelija kirjoitti:
Ylläpito vaikeutuu myös silloin jos käytetään kolmatta vaikka ensinmäinen tai toinen normaalimuoto sopisi tarkoitukseen paremmin.
Tarkoitatko että normalisointisäännöistä valittaisiin jokin? Sikäli kuin minulle on opetettu, normalisointi pitää sisällään nuo kolme perussäätöä (sekä joitain muita valinnaisia, joihin en ole tutustunut) joiden kaikkien tulee toteutua jotta voitaisiin puhua normalisoidusta rakenteesta. Toki se voidaan denormalisoida, mutta silloinhan ei enään voida puhua normaalimuodosta (kuten nimikin jo sanoo).
Opiskelija kirjoitti:
JTS kirjoitti:
ellei sitten palvelinteho todellakin ole riittämätön normaalimuotojen mukaisen tietokantamallin ajamiseen (jolloin mielestäni oikea ratkaisu on lisätä palvelintehoja).
Mutta kannattaa miettiä kannattaako palvelintehojen lisäyksestä maksaa paljon jos sama asia saavutetaan denormalisoinnilla. Tämä tietenkin silloin kun puhutaan huomattavasti suuremmista kuin muutama tuhat hakua päivässä.
Ilmaisin itseäni ehkä vähän huonosti, tarkoitin lähinnä yritystason toimintaa. Jossain harrastelijatason toiminnassa denormalisointi voi auttaa, mutta yritystasolla se rauta on halpaa, ja työ (ja ongelmatilanteet) kallista.
JTS kirjoitti:
Tarkoitatko että normalisointisäännöistä valittaisiin jokin? Sikäli kuin minulle on opetettu, normalisointi pitää sisällään nuo kolme perussäätöä (sekä joitain muita valinnaisia, joihin en ole tutustunut) joiden kaikkien tulee toteutua jotta voitaisiin puhua normalisoidusta rakenteesta.
Kyllä se ensimmäinen normaalimuoto on saavutettu, kun sen ensimmäisen vaatimukset täyttyvät. Tuo kolmas (tai se jonkun hepun nimi jota en nyt muista -muoto) normaalimuoto on vaan se tavallisin, kun sillä saavutetaan useimmissa tapauksissa kaikki tarvittava hyöty, ja se on vielä kohtuullisen ymmärrettävä. Normalisoinnissa mennään tasoja ylöspäin, denormalisoinnissa alaspäin (tosin jälkimmäisessä ei välttämättä järjestyksessä).
lainaus:
Ilmaisin itseäni ehkä vähän huonosti, tarkoitin lähinnä yritystason toimintaa. Jossain harrastelijatason toiminnassa denormalisointi voi auttaa, mutta yritystasolla se rauta on halpaa, ja työ (ja ongelmatilanteet) kallista.
Kyllä denormalisointi on nimenomaan järeiden sovellusten työkalu, jolla saavutetaan tarvittava nopeus ylläpidon tms. kustannuksella, kun normaalimuotojen mukainen kanta käy vaan liian raskaaksi suurilla käyttäjämäärillä. Harrastelijatasolla, missä olen itse saanut autuaasti pysytellä, on harvoin syytä alkaa denormalisoimaan.
Kysymykseen, jos tunnus on kohtuullisen lyhyt (ja vakiomittainen), niin sille vaan indeksi jolloin ei pitäisi normaalilla koneella juuri hidastua (jos siis kyse nimenomaan yksittäisen tunnuksen hausta per kommenttirivi). Tunnukset on varmaan hyvä olla yksilöllisiä, niin UNIQUE-indeksillä kaksi kärpästä yhdellä iskulla.
Kaipa tuo normalisoinnista yleiseisesti puhuminen ei sitten ole vakiintunutta sanastoa. Meidän relaatiotietokantojen opettaja käytti/käyttää sitä noin "onko se normaalimuodossa" tarkoittaen että onko se normalisoitu kolmanteen tasoon.
Aihe on jo aika vanha, joten et voi enää vastata siihen.