Mitenköhän saisi kätsysti selville onko sql-taulussa jokin sarake vai ei? Pitäisi saada lisättyä sellainen mikäli sitä ei löydy.
Oletetaan että taulussa on jo ainakin sarakkeet 'id', 'sana', 'sarakeX' ja 'sarakeY'.
Nyt meillä on toisaalla määritelty taulukko, jossa määritellään mitkä sarakkeet halutaan taulussa olevan. 'id' ja 'sana' on aina, mutta muualla määritellään mitä muuta pitää olla.
Taulukko on määritelty seuraavalla tavalla:
$sarakkeet = array("sarakeX", "sarakeY", "sarakeZ");
Nyt pitäisi siis selvittää onko sql-taulussa 'sarakeY'. Jollei ole, niin se luodaan loppuun.
Seuraavaksi selvitetään onko taulussa 'sarakeZ', ja jollei ole niin se luodaan jne.
Mitenkä tämän saisi tehtyä?
Oletetaan että taulussa on jo ainakin sarakkeet 'id', 'sana', 'sarakeX' ja 'sarakeY'.
Nyt meillä on toisaalla määritelty taulukko, jossa määritellään mitkä sarakkeet halutaan taulussa olevan. 'id' ja 'sana' on aina, mutta muualla määritellään mitä muuta pitää olla.
Taulukko on määritelty seuraavalla tavalla:
$sarakkeet = array("sarakeX", "sarakeY", "sarakeZ");
Nyt pitäisi siis selvittää onko sql-taulussa 'sarakeY'. Jollei ole, niin se luodaan loppuun.
Seuraavaksi selvitetään onko taulussa 'sarakeZ', ja jollei ole niin se luodaan jne.
Mitenkä tämän saisi tehtyä?
Vastaukset 18
Vanhimmat
Lisään joka kerralla kaikki sarakkeet niin sarake lisätään mikäli sitä ei ole. Hidastaahan tuo hieman, mutta tämä on ylläpitoscripti joten ei ole mitenkään yleisesti käytetty.
Taulukon sarakkeiden nimet saa selville käyttämällä PHP:n mysql_fetch_field funktiota.
Pari asiaa kuitenkin kummastuttaa:
"Lisään joka kerralla kaikki sarakkeet niin sarake lisätään mikäli sitä ei ole."
- Joka kerralla? Tietokanta suunnitellaan kerralla kuntoon eikä sinne lähdetä lisäilemään sarakkeita mielivaltaisesti. Ilmeisesti kantaa ei ole suunniteltu kovinkaan hyvin jos tietokannan rakennetta pitää muutella yhtenään. Voitko kertoa hieman lisää mitä oikein säilytät kannassa ja mihin tarkoitukseen se on tehty? Kannan rakenteeseen saattaisi löytyä joku järkevämpikin kuin käyttämäsi ratkaisu.
Taulussa on monikielisten sivujen sanastoa. Pitäisi saada helposti lisättyä uusia kieliä.
Eikö helpointa olisi tehdä jokaisesta kielestä oma kielitiedosto ja vaihtaa sitä sen mukaan mikä kieli on valittuna?
Jos taas tarkoitus on tehdä sanakirja, riittää kun tekee kolme taulua. Ensimmäiseen tauluun lisätään suomenkielinen sana sekä avain, linkitetään se välitaulun kanssa kolmanteen tauluun, joka sisältää avaimen, sekä selitteen kaikilla muilla kielillä. Uusia sarakkeita ei tarvitse tehdä kun halutaan lisätä uusi kieli, riittää kun sanan merkitys lisätään kolmanteen tauluun ja linkitetään oikeaan sanaan ensimmäisessä taulussa.
Sanat
SANA_ID | SANA | KIELI_ID
Liitos
LIITOS_ID | SANA_ID | SANA_ID_2
Selitteet
SELITE_ID | SANA_ID | SELITE
Tuo on toki hieman pitemmälle jalostettu. Mutta jos halutaan pelkästään sama mitä sinä niin silloin jätetään vain selitetaulu pois. Tuolloin lähde ja kohde kielillä ei ole merkitystä. Sinullahan on suomenkielinen ja kolmas taulu samanlainen.
Lisätään vielä, että riippuen miten noita kieliä lisätään/poistetaan voisi olla järkevintä tehdä neljäs taulu
Kielet
KIELI_ID | KIELI
Tai sitten tuo laitetaan config tiedostoon.
"Eikö helpointa olisi tehdä jokaisesta kielestä oma kielitiedosto ja vaihtaa sitä sen mukaan mikä kieli on valittuna?"
Kyllä ja ei, mikäli tarkoitetaan sivun valikoita jne.... Kyllä tuohon tietokantaakin kannattaa käyttää on meinaan paljon helpompa hallita ja muokata kuin kielitiedostoja. Tosin järkevintä olisi ehkä pitää sanat tietokannassa aina kun niitä muutetaan niin automaattisesti tehtäisiin kielitiedostot tai jopa valmiit sivutkin.
En ymmärrä miksi minun pitäisi tehdä useampia tauluja yhtä helkutin sanastoa varten. Sanaston tallennan tietokantaan josta se on helppo lukea ja taas tallentaa päivitystyökalulla. Aina kun sanastoa päivitetään kantaan, tallennetaan jokaisesta kielestä oma kielitiedosto joka sitten voidaan includata sivuille.
Tietokanta on siis nimenomaan ainostaan hallinnan helpottamiseksi.
Tällaista olen siis väsäämässä.
taulu
id, sana_id, sana, kieli
esim
1, 1, Lähetä, fi
2, 1, Submit, en
3, 2, Tyhjennä, fi
4, 2, Reset, en
käännös suomesta englanniksi yksinkertaistetuilla kahdella kyselyllä jotta idea käy selväksi
wid = select sana_id from sanasto where sana = ... and kieli = 'fi'
sana = select sana from sanasto where sana_id = wid and kieli = 'en'
"En ymmärrä miksi minun pitäisi tehdä useampia tauluja yhtä helkutin sanastoa varten. "
Suosittelen tutustumaan relaatiotietokannan perusteisiin, etenkin normalisointiin. Vaikkapa http://sarja.internetix.fi/fi/sisalto/materiaalit/access2003/luku03?C:D=419702&selres=419702
"Sanaston tallennan tietokantaan josta se on helppo lukea ja taas tallentaa päivitystyökalulla."
Toki moneen tauluun on hitusen vaikeempa tallentaa, edellyttää vain muutaman rivin koodia enempi tai sit teet proseduurin joka hoitaa tuon. Luku onnistuu helposti ihan perus liitoksilla.
enkä näe pienintäkään syytä miksi käyttää useampaa taulua tuossa tapauksessa. Voinet perustella?
"Itse olen tutustunut syvällisemminkin enkä näe pienintäkään syytä miksi käyttää useampaa taulua tuossa tapauksessa. Voinet perustella?"
Nyt on kiire, mutta perusteluiksi varmaankin riittänee Nöösin ratkaisu. "Lisään joka kerralla kaikki sarakkeet niin sarake lisätään mikäli sitä ei ole". Tuolloin taulun rakenne muuttuu usein, sekä jos kieliä on useita niin silloin sarakkeitakin on tuhottomasti, kun useamman taulun ratkaisussa sarakkeita ei tarvitsisi muuttaa.
Ja tuolloin datan hallinta vaikeutuu ja hidastuu, esim halutaan poistaa suomenkieli tuolloin joudutaan poistamaan yksi sarake tietokannasta taulujen muutokset ovat hitaita varsinkin isommilla data määrille sekä indeksit joudutaan tuolloin rakentamaan uusiksi.
Voinetko sinä perustella miksi tuo taulun jatkuva muokkaaminen olisi hyvä ratkaisu?
Jos tuon haluaa tehdä yhdellä taululla niin silloin kjfdlksjlk ehdottamalla tavalla, joskin järkevimmin kyselyin, joko alikyselyllä tai liitos itseensä.
Mutta sitten tullaan siihen kysymykseen kannattaako tuota normalisoida erillisellä liitostaululla kuten esimerkissäni, tämä mahdollistaa jatkossa paremman laajennattavuuden jne... Toki pitäisi tietää tarkalleen mihkä tuota tarttee ja muitakin asioita.
Tuossa yhdessä taulussa tulee toistoa jos yhdellä sanalla on useampi merkitys jne...
Toki useat jutut voidaan tehdä yhdellä taululla, mutta useinkaan se ei ole järkevin ratkaisu.
Miksi ei yhden taulun simppeli ratkaisu ole riittävä kuten sinäkin esitit aluksi (mutta vedit siihen turhaan mukaan kaksi taulua lisää)?
"SANA_ID | SANA | KIELI"
Mitään muuta ei tarvita.
identifioi sanan universaalisesti,
esim 123|sana|fi, 123|word|en
"Miksi ei yhden taulun simppeli ratkaisu ole riittävä kuten sinäkin esitit aluksi (mutta vedit siihen turhaan mukaan kaksi taulua lisää)?"
Vai turhat taulut?
Myönnän että tuo selite taulu on tuollaisenaan turha, parempi olisi
Sanat
SANA_ID | SANA | KIELI_ID | SELITE_ID
Liitos
LIITOS_ID | SANA_ID | SANA_ID_2
Selitteet
SELITE_ID | SELITE
"SANA_ID | SANA | KIELI"
Mitään muuta ei tarvita.
identifioi sanan universaalisesti,
esim 123|sana|fi, 123|word|en"
Entäs sanojen lisääminen tuohon, miten selvität mikä SANA_ID seuraava?
Yhä sinun taulurakenteessa on tämä "Tuossa yhdessä taulussa tulee toistoa jos yhdellä sanalla on useampi merkitys jne.." Toki tuo sinun toimii kuten tuo taulujen rakenteen muokkaaminenkin, mutta se ei ole relaatiotietokanta idean mukaista.
"Tuolloin taulun rakenne muuttuu usein, sekä jos kieliä on useita niin silloin sarakkeitakin on tuhottomasti"
Olisin uskonut sinun tietävän, mitä tapahtuu silloin kun tietokantaan lisätään sarake joka on jo olemassa. Silloin ei tapahdu mitään. Ainoastaan virheilmoitus jota sitäkään ei tarvitse näyttää.
Tällöin taulun rakenne muuttuu ainoastaan silloin kun todella lisätään uusi kieli.
Eli jos kieliä on useita niin sarakkeita on useita mutta ei suinkaan tuhottomasti.
Pitää kuitenkin muistaa, etten ole tekemässä mitään kattavaa suomi-kaikkimaailmankielet -sanakirjaa. Tuohon sanastoon tulee lähinnä yleisesti sivulta toiselle toistuvat sanat ja fraasit, varsinainen vaihtuva sivudata on sitten erikseen. En minä sitä nyt ala lennossa kääntämään tuon tietokannan avulla.
"Olisin uskonut sinun tietävän, mitä tapahtuu silloin kun tietokantaan lisätään sarake joka on jo olemassa. Silloin ei tapahdu mitään. Ainoastaan virheilmoitus jota sitäkään ei tarvitse näyttää.
Tällöin taulun rakenne muuttuu ainoastaan silloin kun todella lisätään uusi kieli."
Et tainnut käsittää mitä tuolla tarkoitin. Kun lisäät tai poistat kieliä niin taulun rakenne muuttuu, tätähän et varmaan kiistä?
Pikkuruinen korjaus, että lisäät sarakkeita tauluun et varsinaisesti tietokantaan.
Ja kun rakenne muuttuu noinkin usein niin se vaikeuttaa SQL:n kirjoittamista. Taulurakenteethan suunnitellaan niin, ettei datan lisäyksen tai poisto tarvitse rakennetta muuttaa.
"Ainoastaan virheilmoitus jota sitäkään ei tarvitse näyttää."
Hienoa, ihmetyttää tämä nykyajan koodaaminen, tehdään tarkoituksella virheilmoituksia ja sitten ne piilotetaan.
"jos kieliä on useita niin sarakkeita on useita mutta ei suinkaan tuhottomasti"
Ihan sama, olkoon niitä sarakkeita sitten useita, mutta sekin on huono asia.
"Pitää kuitenkin muistaa, etten ole tekemässä mitään kattavaa suomi-kaikkimaailmankielet -sanakirjaa."
Juu. Mutta kysyn sinulta, vaikka onkin pikkuruinen juttu niin miksi sitä ei voisi tehdä kunnolla kun siinä ei menisi juurikaan yhtään enempää aikaa?
Varsinkin jos olet opettelemassa asioita niin herkästi myöhemminkin tekee asiat tuollee huonosti.
"Et tainnut käsittää mitä tuolla tarkoitin. Kun lisäät tai poistat kieliä niin taulun rakenne muuttuu, tätähän et varmaan kiistä?"
Onko sillä väliä? Eihän se taulun rakenne muutu kuin silloin harvoin kun lisätään kieliä. Ja sitä ei todellakaan tapahdu usein.
"Pikkuruinen korjaus, että lisäät sarakkeita tauluun et varsinaisesti tietokantaan."
Miten vain. Tietokantaan kuitenkin lisään uuden kielen silloin kun sitä ei siellä ole.
"Ja kun rakenne muuttuu noinkin usein niin se vaikeuttaa SQL:n kirjoittamista. Taulurakenteethan suunnitellaan niin, ettei datan lisäyksen tai poisto tarvitse rakennetta muuttaa."
Noinkin usein?
Miten usein kuvittelet minun lisäävän uusia kieliä sivustolle?
"Hienoa, ihmetyttää tämä nykyajan koodaaminen, tehdään tarkoituksella virheilmoituksia ja sitten ne piilotetaan."
Toki voin tehdä tarkastuksen ennen kuin uusi kieli lisätään, mutta nopeuttaako se ahjelman suoritusta? Luultavasti käy päinvastoin.
Näinollen kannattaa tehdä sillä tavalla, millä ohjelman suoritus on nopeinta.
"Ihan sama, olkoon niitä sarakkeita sitten useita, mutta sekin on huono asia."
Onko sitten parempi että tauluja on useita? Mitä hyötyä tästä on?
"Juu. Mutta kysyn sinulta, vaikka onkin pikkuruinen juttu niin miksi sitä ei voisi tehdä kunnolla kun siinä ei menisi juurikaan yhtään enempää aikaa?"
Juu kyllä minä tämän ajattelin kunnolla tehdäkin.
Näkemyksemme taitaa silti hieman poiketa toisistaan.
Kiitos silti kommenteista, laitan kaikki harkintaan.
"Onko sillä väliä? Eihän se taulun rakenne muutu kuin silloin harvoin kun lisätään kieliä. Ja sitä ei todellakaan tapahdu usein."
on, kuten jo totesin niin SQL:n kirjoittaminen vaikeutuu sekä esim UML mallintaminen. Ja kuten jo totesin niin taulu rakennehan ei saa olla riippuvainen datan määrästä.
"Miten vain. Tietokantaan kuitenkin lisään uuden kielen silloin kun sitä ei siellä ole."
Eipäs, nimenomaan lisäät kielen tauluun. Yksinkertaistettuna taulu on kuin tekstitiedosto johon kirjoitat kielen, tietokanta on hakemisto missä on monta taulua(tiedostoa).
"Noinkin usein?
Miten usein kuvittelet minun lisäävän uusia kieliä sivustolle?"
Ihan sama kuinka usein, sillä taulunrakenne ei saa olla riippuvainen tuommosesta asiasta, siis monta kieltä siellä on.
"Toki voin tehdä tarkastuksen ennen kuin uusi kieli lisätään, mutta nopeuttaako se ahjelman suoritusta? Luultavasti käy päinvastoin.
Näinollen kannattaa tehdä sillä tavalla, millä ohjelman suoritus on nopeinta."
Jos kerta ohjelman(kyselyn) suorituksessa on tärkeää nopeus niin miksi sitten et tee asiaa erillaisella taulurakenteella?
Tuolloin ei myöskään tarvitsisi piilotella virheitä. Sekä kun piilotat virheet niin silloin virhetilanteiden selvittely vaikeutuu.
"Onko sitten parempi että tauluja on useita? Mitä hyötyä tästä on?"
On, mutta kuten on jo todettu niin yhdelläkin taululla saa ihan toimivan, kunhan asian tekee vaikkapa kjfdlksjlk neuvoi, tuolloin ei tarvitse taulunrakennetta muutella kun kieliä lisää tai poistaa. Ja nuo hyödythän on jo monessa viestissä mainittu.
"Juu kyllä minä tämän ajattelin kunnolla tehdäkin."
Ihanko totta?
Kunnolla tehty ja suuniteltu taulurakenne toimii pienellä sekä suurella datamäärällä ongelmitta, samoin lisäys/poisto ei rakennetta muuta jne...
Siis jos kieliä on 10 000 ja lisäyksiä/poistoja vaikkapa muutaman kerran tunnissa (siis todella pietä), niin hyvin suunniteltu ja tehty toimii tuolloinkin ongelmitta. Älä nyt takerru noiden kielten määrään, kun kuitenkin ymmärrät mitä tuolla tarkoitan.
"Näkemyksemme taitaa silti hieman poiketa toisistaan."
Voithan toki huviksesi laittaa kysymyksen taulurakenteestasi jonnekkin toiseen keskustelupalstaan vaikkapa http://mureakuha.com tai http://www.sitepoint.com niin tulet huomaamaan, että monet kehottavat vaihtamaan taulurakennetta toisenlaiseksi.
"Kiitos silti kommenteista, laitan kaikki harkintaan."
Jotenkin tuntuu ettet laita, sillä takerrut yksittäisiin sanoihin, etkä halua ymmärtää kokonaisuutta.