Erikieliset sanat tietokannassa

Mitä etuja sillä olisi verrattuna siihen, että tekee 10 taulua jokaiselle kielelle?

1 taulu 10 näkymää VS 10 taulua ????

sillä olisi kirjoitti:

Mitä etuja sillä olisi verrattuna siihen, että tekee 10 taulua jokaiselle kielelle?

1 taulu 10 näkymää VS 10 taulua ????

Etu on siinä, että kaikki data on yhdessä taulussa näin hallinta on helppoa. Sekä ei ole tietokannan periaatteiden mukaista käyttää 10 taulua joissa on vähän dataa samanlaisella taulurakenteella.

Tosin mielestäni tässä ei tartte lähteä kikkailemaan näin.

Ei ole sama kaikille, jos esimerkiksi ei valitse "utf8_swedish_ci" aakkosjärjestykseksi, niin Ä kirjain tulee A:n sekaan ja Ö tulee O:n sekaan, eikä erillisinä kirjaimina. Muistaakseni jopa haku menee sekaisin, eli jos hakee vaikka "äit%" niin se antaa myös sanan "aita", jne..

Enkä edes uskalla veikata mitä tapahtuu jos sinne vielä lisää kyrillisiä sanoja.

Vääräoppinen keino. Tuolla tavalla tulee ongelmia, esim jos jotain termiä ei ole Venäjäksi niin jätät tyhjän arvon, ja tämä on taas tietokannan perusteita vastaan. Ja muitakin ongelmia tuost seuraa.

Ihan vaan tiedoksi, että MySQL onnistuu myös noin.

,,, kirjoitti:

Vääräoppinen keino. Tuolla tavalla tulee ongelmia, esim jos jotain termiä ei ole Venäjäksi niin jätät tyhjän arvon, ja tämä on taas tietokannan perusteita vastaan. Ja muitakin ongelmia tuost seuraa.

Ihan vaan tiedoksi, että MySQL onnistuu myös noin.

Lue lisää

Missäs suorititkaan yliopistotason tietojenkäsittelykurssisi, peelo? Null on ihan validi tieto, josta ei seuraa yhtään mitään ongelmia.

(FileMaker Pro) kirjoitti:

Missäs suorititkaan yliopistotason tietojenkäsittelykurssisi, peelo? Null on ihan validi tieto, josta ei seuraa yhtään mitään ongelmia.

Mikä siinä on että täytyy ruveta haukkumaan heti jos joku arvostelee taulukkorakennettasi?

Totta että Null on ihan validi tieto, mutta se ei poista sitä asiaa, että tuo taulukkorakenne on vääräoppinen.

Ajatteleppas tilanne lisäät vaikka Kiinan kielen jossa on vain muutama termi, tällöin sinulla on taulukossasi Kiinan kohdalla nulleja moninkertaisesti se mitä itse tietoja. Tietokannan perusteisiin kuuluu, että turhaa toistoa yritetään vähentää, sekä tietokanta on tietoja varten ei nulleja.

Lukaseppas vaikka ens alkuun http://appro.mit.jyu.fi/2002/kevat/tietokannat/luennot/luento4/ ja http://fi.wikipedia.org/wiki/Tietokannan_normalisointi lisää löydät Googlel.

Täällä on rivi per kieli, eikä per sarake. Joten ei ole hyötyä mulle.

Ja ehkä leikkitietokannaksi FileMaker (MS Accessin korvike Macille?) sopii, mutta kun rivejä on reilut 3,5 miljoonaa (ja tietokannan koko on yli 600Mt) niin en oikein usko, että toimisi yhtä hyvin kuin MySQL. Eikä sille tietääkseni ole edes PHP rajapintaa, ja se on välttämättömyys tässä projektissa.

(MySQL) kirjoitti:

Täällä on rivi per kieli, eikä per sarake. Joten ei ole hyötyä mulle.

Ja ehkä leikkitietokannaksi FileMaker (MS Accessin korvike Macille?) sopii, mutta kun rivejä on reilut 3,5 miljoonaa (ja tietokannan koko on yli 600Mt) niin en oikein usko, että toimisi yhtä hyvin kuin MySQL. Eikä sille tietääkseni ole edes PHP rajapintaa, ja se on välttämättömyys tässä projektissa.

Lue lisää

Sen tarve ei kysymyksestäsi käynyt ilmi. Periaatteessa rakenteesi on varmaankin oikea (ainakaan nopeasti en keksi parempaa).

Tietokannan koko on kuitenkin Hyvin Suhteellinen Käsite ja riippuu mm. siitä, kuinka tehokkaita tai "hyödyllisiä" indeksit ovat. Mutta olet oikeassa siinä, että FileMaker toimii parhaiten suhteellisen "neliömäisillä" taulukoilla TAI tiukasti fokusoiduilla relaatioilla. Sinänsä muutama miljoona riviä tai jokunen gigatavu eivät ole ongelma FileMakerille ja kannan voi heittää nettiin ihan noin vain - tietyin rajoituksin.

En kuitenkaan usko, että rivipohjainen "sorting" toimii haluamallasi tavalla millään softalla. Jotenkin (kai) pitäisi saada "found set" sortattua omalla tavallaan?

,,, kirjoitti:

Mikä siinä on että täytyy ruveta haukkumaan heti jos joku arvostelee taulukkorakennettasi?

Totta että Null on ihan validi tieto, mutta se ei poista sitä asiaa, että tuo taulukkorakenne on vääräoppinen.

Ajatteleppas tilanne lisäät vaikka Kiinan kielen jossa on vain muutama termi, tällöin sinulla on taulukossasi Kiinan kohdalla nulleja moninkertaisesti se mitä itse tietoja. Tietokannan perusteisiin kuuluu, että turhaa toistoa yritetään vähentää, sekä tietokanta on tietoja varten ei nulleja.

Lukaseppas vaikka ens alkuun http://appro.mit.jyu.fi/2002/kevat/tietokannat/luennot/luento4/ ja http://fi.wikipedia.org/wiki/Tietokannan_normalisointi lisää löydät Googlel.

Lue lisää

Ei tuo NULL vie paljoakaan tilaa, paitsi jos sarakkeiden koko on kiinteä.

Mutta jossain tapauksissa tuokin "vääräoppinen" rakenne voi olla hyvä. FileMaker tyyppi varmasti tarkoitti jotain sanakirjaa tapaista rakennetta, että taulu on joksekin tällainen:

id, suomi, enkku, ruotsi, saksa, ranska, jne..

Ja jos lisäämme vaikka rivin:

1, talo, house, NULL, NULL, NULL, NULL
2, talo, NULL, hus, NULL, NULL, NULL
3, NULL, house, hus, NULL, NULL, NULL

(Tuonkin voisi laittaa samalle riville..)

Nyt voimme helposti toteuttaa käännökset suomi-*, englanti-*, ruotsi-*, jne..

SELECT * FROM sanasto WHERE suomi LIKE 'talo'
tai
SELECT * FROM sanasto WHERE enkku LIKE 'house'
tai
SELECT * FROM sanasto WHERE ruotsi LIKE 'hus'

Mutta jos meillä olisivat kielet per rivi? Tuosta tulisi huomattavasti monimutkaisempi rakenne ja kysely:

id, sana1, sana2, kieli1, kieli2

1, talo, house, suomi, enkku
2, hus, house, ruotsi, enkku
3, hus, talo, ruotsi, suomi
jne..

Miten tuosta edes hakisi sanan "talo" käännökset???

SELECT sana1, sana2 FROM sanasto WHERE kieli1 = "suomi" AND sana1 LIKE 'talo'
UNION
SELECT sana2, sana1 FROM sanasto WHERE kieli2 = "suomi" AND sana2 LIKE 'talo'

Eli tuli kaksi kyselyä, koska emme voi tietää missä sarakkeessa on suomenkielinen sana, missä on ruotsinkielinen, englanninkielinen tai vaikka kiinankielinen...

Mielestäni tässä tapauksessa FileMaker Pro tyypin ratkaisu olisi parempi, vaikka se onkin vääräoppinen.

tuossakin voisi olla.... kirjoitti:

Ei tuo NULL vie paljoakaan tilaa, paitsi jos sarakkeiden koko on kiinteä.

Mutta jossain tapauksissa tuokin "vääräoppinen" rakenne voi olla hyvä. FileMaker tyyppi varmasti tarkoitti jotain sanakirjaa tapaista rakennetta, että taulu on joksekin tällainen:

id, suomi, enkku, ruotsi, saksa, ranska, jne..

Ja jos lisäämme vaikka rivin:

1, talo, house, NULL, NULL, NULL, NULL
2, talo, NULL, hus, NULL, NULL, NULL
3, NULL, house, hus, NULL, NULL, NULL

(Tuonkin voisi laittaa samalle riville..)

Nyt voimme helposti toteuttaa käännökset suomi-*, englanti-*, ruotsi-*, jne..

SELECT * FROM sanasto WHERE suomi LIKE 'talo'
tai
SELECT * FROM sanasto WHERE enkku LIKE 'house'
tai
SELECT * FROM sanasto WHERE ruotsi LIKE 'hus'

Mutta jos meillä olisivat kielet per rivi? Tuosta tulisi huomattavasti monimutkaisempi rakenne ja kysely:

id, sana1, sana2, kieli1, kieli2

1, talo, house, suomi, enkku
2, hus, house, ruotsi, enkku
3, hus, talo, ruotsi, suomi
jne..

Miten tuosta edes hakisi sanan "talo" käännökset???

SELECT sana1, sana2 FROM sanasto WHERE kieli1 = "suomi" AND sana1 LIKE 'talo'
UNION
SELECT sana2, sana1 FROM sanasto WHERE kieli2 = "suomi" AND sana2 LIKE 'talo'

Eli tuli kaksi kyselyä, koska emme voi tietää missä sarakkeessa on suomenkielinen sana, missä on ruotsinkielinen, englanninkielinen tai vaikka kiinankielinen...

Mielestäni tässä tapauksessa FileMaker Pro tyypin ratkaisu olisi parempi, vaikka se onkin vääräoppinen.

Lue lisää

Siis että laittaa kaikki käännökset samalle riville ja indeksointi/aakkostus on sarakekohtainen.

Vaihtuvapituisilla sarakkeilla tietokannan koko ei kasva edes mitattavalla tavalla NULL-arvoilla.

Katsotaanpas. Olikos se 10 kieltä, joista tuli 3,5 miljoonaa riviä? Tyhjä FileMaker Pro taulu, jossa on 10 kielen sarakkeet, on 24 kt ja kun siihen laittaa 350000 riviä NULL-arvoin, on koko näköjään 1,3 megaa. Epäilemättä aivan täyden moisen tietokannan koko on jo huomattava - mutta mistä ihmeestä saadaan 350000 sanaa? 20-osaisessa Oxford English Dictionaryssä on puoli miljoonaa sanaa ja se lienee maailman suurin sanakirja. WSOY:n suomi-englanti sanakirjassa on 62000 hakusanaa, 1500-sivuisessa suursanakirjassa 160000.

"Oikeaoppinen" ratkaisu taitaa edellyttää "pääkieltä"?

ID, sana_pääkielellä, kieli, sana_kielellä

(FileMaker Pro) kirjoitti:

Siis että laittaa kaikki käännökset samalle riville ja indeksointi/aakkostus on sarakekohtainen.

Vaihtuvapituisilla sarakkeilla tietokannan koko ei kasva edes mitattavalla tavalla NULL-arvoilla.

Katsotaanpas. Olikos se 10 kieltä, joista tuli 3,5 miljoonaa riviä? Tyhjä FileMaker Pro taulu, jossa on 10 kielen sarakkeet, on 24 kt ja kun siihen laittaa 350000 riviä NULL-arvoin, on koko näköjään 1,3 megaa. Epäilemättä aivan täyden moisen tietokannan koko on jo huomattava - mutta mistä ihmeestä saadaan 350000 sanaa? 20-osaisessa Oxford English Dictionaryssä on puoli miljoonaa sanaa ja se lienee maailman suurin sanakirja. WSOY:n suomi-englanti sanakirjassa on 62000 hakusanaa, 1500-sivuisessa suursanakirjassa 160000.

"Oikeaoppinen" ratkaisu taitaa edellyttää "pääkieltä"?

ID, sana_pääkielellä, kieli, sana_kielellä

Lue lisää

"Mutta jossain tapauksissa tuokin "vääräoppinen" rakenne voi olla hyvä."

En väittänytkään että se on aina huono, luvitkos edes mitä linkitin?

Katso http://fi.wikipedia.org/wiki/Tietokannan_normalisointi ja ensinmäinen osio.

Toki huono kantarakenne toimii mikäli käyttäjiä vähän ja muutenkin haluaa kikkailla. Jos sanakirjaa haluaa laajentaa lisäominaisuuksilla jne... niin hyvin suunniteltu kantarakenne mahdollistaa sen helposti. FileMaker Pro tyyppisissä ratkaisuissa usein kantarakenne on helpointa suunitella kokonaan uusiksi ja syöttää sanat uudestaan.


"1, talo, house, NULL, NULL, NULL, NULL
2, talo, NULL, hus, NULL, NULL, NULL
3, NULL, house, hus, NULL, NULL, NULL"

Jep jep, näin sinulla on taulussa esim useita taloja miksi?
Entäs sitten jos Suomenkielistä sanaa vastaa Englanniksi monta, sitten on vielä enempi samoja sanoja taulukos. Tätä asiaa normalisoinnilla vähennetään.


"Mutta jos meillä olisivat kielet per rivi? Tuosta tulisi huomattavasti monimutkaisempi rakenne ja kysely:

id, sana1, sana2, kieli1, kieli2...
Mielestäni tässä tapauksessa FileMaker Pro tyypin ratkaisu olisi parempi, vaikka se onkin vääräoppinen."

Olet oikeessa siinä että FileMaker Pro tyypin ratkaisu on parempa noista kahdesta, mutta kuka tuommoista taulukko rakennetta on ehdottanut?

Ilmeisesti sinulle on vieraita käsitteet normalisointi ja liitokset jne..?


"Vaihtuvapituisilla sarakkeilla tietokannan koko ei kasva edes mitattavalla tavalla NULL-arvoilla."

Kuten huomaat yllä ongelma ei koske yksinomaan NULL-arvoja vaan muitakin.


""Oikeaoppinen" ratkaisu taitaa edellyttää "pääkieltä"?

ID, sana_pääkielellä, kieli, sana_kielellä"

Sinullekkin taitaa olla vieraita käsitteitä normalisointi ja liitokset?

Tehdään vaikkapa
sana_id | sana | kieli_id

tämän jälkeen vain vain liitostaulu jossa yhdistetään ideet toisiinsa.

Jos haluat lisätä esim jollekkin yksittäiselle Ruotsinkielen sanalle selitteen tai esimerkin sen käytöstä tämä onnistuu helposti. Tekemällä vain selitteet taulu johon lisäät sana_id (sen sanan mille selite on) ja selitteen.

Mites sinä FileMaker Pro toteuttaisit tämän omassa taulukko rakenteessa?

,,, kirjoitti:

"Mutta jossain tapauksissa tuokin "vääräoppinen" rakenne voi olla hyvä."

En väittänytkään että se on aina huono, luvitkos edes mitä linkitin?

Katso http://fi.wikipedia.org/wiki/Tietokannan_normalisointi ja ensinmäinen osio.

Toki huono kantarakenne toimii mikäli käyttäjiä vähän ja muutenkin haluaa kikkailla. Jos sanakirjaa haluaa laajentaa lisäominaisuuksilla jne... niin hyvin suunniteltu kantarakenne mahdollistaa sen helposti. FileMaker Pro tyyppisissä ratkaisuissa usein kantarakenne on helpointa suunitella kokonaan uusiksi ja syöttää sanat uudestaan.


"1, talo, house, NULL, NULL, NULL, NULL
2, talo, NULL, hus, NULL, NULL, NULL
3, NULL, house, hus, NULL, NULL, NULL"

Jep jep, näin sinulla on taulussa esim useita taloja miksi?
Entäs sitten jos Suomenkielistä sanaa vastaa Englanniksi monta, sitten on vielä enempi samoja sanoja taulukos. Tätä asiaa normalisoinnilla vähennetään.


"Mutta jos meillä olisivat kielet per rivi? Tuosta tulisi huomattavasti monimutkaisempi rakenne ja kysely:

id, sana1, sana2, kieli1, kieli2...
Mielestäni tässä tapauksessa FileMaker Pro tyypin ratkaisu olisi parempi, vaikka se onkin vääräoppinen."

Olet oikeessa siinä että FileMaker Pro tyypin ratkaisu on parempa noista kahdesta, mutta kuka tuommoista taulukko rakennetta on ehdottanut?

Ilmeisesti sinulle on vieraita käsitteet normalisointi ja liitokset jne..?


"Vaihtuvapituisilla sarakkeilla tietokannan koko ei kasva edes mitattavalla tavalla NULL-arvoilla."

Kuten huomaat yllä ongelma ei koske yksinomaan NULL-arvoja vaan muitakin.


""Oikeaoppinen" ratkaisu taitaa edellyttää "pääkieltä"?

ID, sana_pääkielellä, kieli, sana_kielellä"

Sinullekkin taitaa olla vieraita käsitteitä normalisointi ja liitokset?

Tehdään vaikkapa
sana_id | sana | kieli_id

tämän jälkeen vain vain liitostaulu jossa yhdistetään ideet toisiinsa.

Jos haluat lisätä esim jollekkin yksittäiselle Ruotsinkielen sanalle selitteen tai esimerkin sen käytöstä tämä onnistuu helposti. Tekemällä vain selitteet taulu johon lisäät sana_id (sen sanan mille selite on) ja selitteen.

Mites sinä FileMaker Pro toteuttaisit tämän omassa taulukko rakenteessa?

Lue lisää

"Jos haluat lisätä esim jollekkin yksittäiselle Ruotsinkielen sanalle selitteen tai esimerkin sen käytöstä tämä onnistuu helposti. Tekemällä vain selitteet taulu johon lisäät sana_id (sen sanan mille selite on) ja selitteen.

Mites sinä FileMaker Pro toteuttaisit tämän omassa taulukko rakenteessa?"

Mikäs on vikana erillisessä esimerkkitaulussa? Onko se jotenkin huonompi rakenne kuin 3,5 miljoonaa NULL-arvoa siinä ainoassa taulussa? Miten toteuttaisit n (n>1) selitettä tai m esimerkkiä (m>1) kielellä tässä MySQL:n "oikeaoppisessa" yhden taulun rakenteessa?

(FileMaker Pro) kirjoitti:

"Jos haluat lisätä esim jollekkin yksittäiselle Ruotsinkielen sanalle selitteen tai esimerkin sen käytöstä tämä onnistuu helposti. Tekemällä vain selitteet taulu johon lisäät sana_id (sen sanan mille selite on) ja selitteen.

Mites sinä FileMaker Pro toteuttaisit tämän omassa taulukko rakenteessa?"

Mikäs on vikana erillisessä esimerkkitaulussa? Onko se jotenkin huonompi rakenne kuin 3,5 miljoonaa NULL-arvoa siinä ainoassa taulussa? Miten toteuttaisit n (n>1) selitettä tai m esimerkkiä (m>1) kielellä tässä MySQL:n "oikeaoppisessa" yhden taulun rakenteessa?

Lue lisää

"Mikäs on vikana erillisessä esimerkkitaulussa? Onko se jotenkin huonompi rakenne kuin 3,5 miljoonaa NULL-arvoa siinä ainoassa taulussa?"

Erilliseenhän tauluun nuo kannattaa laittaa näinhän tuossa aikasemmassa viestissä kerroinkin, mutta sinun ratkaisussasi ongelmaksi tulee se miten yhdistät tietyn sanan sen esimerkkiin. Toki kikkailemalla saat jotenkin toimivan.


"Miten toteuttaisit n (n>1) selitettä tai m esimerkkiä (m>1) kielellä tässä MySQL:n "oikeaoppisessa" yhden taulun rakenteessa?"

Siis missä ihmeen yhdentaulun rakenteessa?

Jos tuota minun juttua meinaat niin ihan yksinkertaisella liitoksella.

,,, kirjoitti:

"Mikäs on vikana erillisessä esimerkkitaulussa? Onko se jotenkin huonompi rakenne kuin 3,5 miljoonaa NULL-arvoa siinä ainoassa taulussa?"

Erilliseenhän tauluun nuo kannattaa laittaa näinhän tuossa aikasemmassa viestissä kerroinkin, mutta sinun ratkaisussasi ongelmaksi tulee se miten yhdistät tietyn sanan sen esimerkkiin. Toki kikkailemalla saat jotenkin toimivan.


"Miten toteuttaisit n (n>1) selitettä tai m esimerkkiä (m>1) kielellä tässä MySQL:n "oikeaoppisessa" yhden taulun rakenteessa?"

Siis missä ihmeen yhdentaulun rakenteessa?

Jos tuota minun juttua meinaat niin ihan yksinkertaisella liitoksella.

Lue lisää

"sinun ratkaisussasi ongelmaksi tulee se miten yhdistät tietyn sanan sen esimerkkiin. Toki kikkailemalla saat jotenkin toimivan."

Omat sovellukseni tosin yleensä toimivat "luonnollisella" struktuurilla (ilman eksplisiittistä IDtä), mutta toisinaan niitä tarvitaan. Ei liene "kikkailua" muodostaa relaatiolinkki vaikkapa tietueen numerolla tai millä tahansa "unique key" -arvolla?

,,, kirjoitti:

"Mikäs on vikana erillisessä esimerkkitaulussa? Onko se jotenkin huonompi rakenne kuin 3,5 miljoonaa NULL-arvoa siinä ainoassa taulussa?"

Erilliseenhän tauluun nuo kannattaa laittaa näinhän tuossa aikasemmassa viestissä kerroinkin, mutta sinun ratkaisussasi ongelmaksi tulee se miten yhdistät tietyn sanan sen esimerkkiin. Toki kikkailemalla saat jotenkin toimivan.


"Miten toteuttaisit n (n>1) selitettä tai m esimerkkiä (m>1) kielellä tässä MySQL:n "oikeaoppisessa" yhden taulun rakenteessa?"

Siis missä ihmeen yhdentaulun rakenteessa?

Jos tuota minun juttua meinaat niin ihan yksinkertaisella liitoksella.

Lue lisää

Taannoin mekastit näin:

"Etu on siinä, että kaikki data on yhdessä taulussa näin hallinta on helppoa. Sekä ei ole tietokannan periaatteiden mukaista käyttää 10 taulua joissa on vähän dataa samanlaisella taulurakenteella."

(FileMaker Pro) kirjoitti:

"sinun ratkaisussasi ongelmaksi tulee se miten yhdistät tietyn sanan sen esimerkkiin. Toki kikkailemalla saat jotenkin toimivan."

Omat sovellukseni tosin yleensä toimivat "luonnollisella" struktuurilla (ilman eksplisiittistä IDtä), mutta toisinaan niitä tarvitaan. Ei liene "kikkailua" muodostaa relaatiolinkki vaikkapa tietueen numerolla tai millä tahansa "unique key" -arvolla?

Lue lisää

"Ei liene "kikkailua" muodostaa relaatiolinkki vaikkapa tietueen numerolla tai millä tahansa "unique key" -arvolla?"

Ei, mutta mistä sinä tuon unique keyn muodostat tässä tapauksessa?

Sana ei käy koska käänös voi olla sama useilla kielillä.

Ilmeisesti teet sen näin
suomi, selite_suomi, ruotsi, selite_ruotsi...

Ja sitten jos tarttee lisää tietoja niin eikun lisää sarakkeita ja null arvoja vain.

(FileMaker Pro) kirjoitti:

Taannoin mekastit näin:

"Etu on siinä, että kaikki data on yhdessä taulussa näin hallinta on helppoa. Sekä ei ole tietokannan periaatteiden mukaista käyttää 10 taulua joissa on vähän dataa samanlaisella taulurakenteella."

Lue lisää

"Taannoin mekastit näin:..."

Et sitten huomannut mihkä viestiin tuolleen olin vastannut?

Kyse oli 1 taulu 10 näkymää VS 10 taulua.


Sinänsä koomista näinkin pienestä ja yksinkertaisesta asiasta kehkeytyy tämmöinen väittely. Kysy vaikka keneltä tietokanta gurulta niin minun ratkaisuni on parempa kuin sinun yhentaulun hömpsötys.

,,, kirjoitti:

"Mutta jossain tapauksissa tuokin "vääräoppinen" rakenne voi olla hyvä."

En väittänytkään että se on aina huono, luvitkos edes mitä linkitin?

Katso http://fi.wikipedia.org/wiki/Tietokannan_normalisointi ja ensinmäinen osio.

Toki huono kantarakenne toimii mikäli käyttäjiä vähän ja muutenkin haluaa kikkailla. Jos sanakirjaa haluaa laajentaa lisäominaisuuksilla jne... niin hyvin suunniteltu kantarakenne mahdollistaa sen helposti. FileMaker Pro tyyppisissä ratkaisuissa usein kantarakenne on helpointa suunitella kokonaan uusiksi ja syöttää sanat uudestaan.


"1, talo, house, NULL, NULL, NULL, NULL
2, talo, NULL, hus, NULL, NULL, NULL
3, NULL, house, hus, NULL, NULL, NULL"

Jep jep, näin sinulla on taulussa esim useita taloja miksi?
Entäs sitten jos Suomenkielistä sanaa vastaa Englanniksi monta, sitten on vielä enempi samoja sanoja taulukos. Tätä asiaa normalisoinnilla vähennetään.


"Mutta jos meillä olisivat kielet per rivi? Tuosta tulisi huomattavasti monimutkaisempi rakenne ja kysely:

id, sana1, sana2, kieli1, kieli2...
Mielestäni tässä tapauksessa FileMaker Pro tyypin ratkaisu olisi parempi, vaikka se onkin vääräoppinen."

Olet oikeessa siinä että FileMaker Pro tyypin ratkaisu on parempa noista kahdesta, mutta kuka tuommoista taulukko rakennetta on ehdottanut?

Ilmeisesti sinulle on vieraita käsitteet normalisointi ja liitokset jne..?


"Vaihtuvapituisilla sarakkeilla tietokannan koko ei kasva edes mitattavalla tavalla NULL-arvoilla."

Kuten huomaat yllä ongelma ei koske yksinomaan NULL-arvoja vaan muitakin.


""Oikeaoppinen" ratkaisu taitaa edellyttää "pääkieltä"?

ID, sana_pääkielellä, kieli, sana_kielellä"

Sinullekkin taitaa olla vieraita käsitteitä normalisointi ja liitokset?

Tehdään vaikkapa
sana_id | sana | kieli_id

tämän jälkeen vain vain liitostaulu jossa yhdistetään ideet toisiinsa.

Jos haluat lisätä esim jollekkin yksittäiselle Ruotsinkielen sanalle selitteen tai esimerkin sen käytöstä tämä onnistuu helposti. Tekemällä vain selitteet taulu johon lisäät sana_id (sen sanan mille selite on) ja selitteen.

Mites sinä FileMaker Pro toteuttaisit tämän omassa taulukko rakenteessa?

Lue lisää

>1, talo, house, NULL, NULL, NULL, NULL
>2, talo, NULL, hus, NULL, NULL, NULL
>3, NULL, house, hus, NULL, NULL, NULL"

>Jep jep, näin sinulla on taulussa esim useita taloja miksi?

Tuo oli vain esimerkki, ja voit hyvinkin laittaa tuon "talo" sanan tilalle sen id numeron "fin" taulusta fin (id, sana).

>Tehdään vaikkapa
>sana_id | sana | kieli_id

>tämän jälkeen vain vain liitostaulu jossa yhdistetään ideet toisiinsa.

Jatka toki esimerkkisi.. Törmäämme jällen samaan ongelmaan "liitostaulussa". Kun sekin on järkevintä toteuttaa "FileMaker Pro" tyypin tavalla. Muutenhan joudumme tekemään taas kaksi kyselyä.

Ja edelleen sun ehdotuksessa "kaikki kielet samassa taulussa" törmäämme siihen aakkosjärjestysongelmaan.

Eli itse ehdotan:

Käännökset (id, fin_id, eng_id, swe_id, jne..)
fin (id, sana, selitys, taivutus, jne..)
eng (id, sana, selitys, taivutus, jne..)
swe (id, sana, selitys, taivutus, jne..)

,,, kirjoitti:

"Taannoin mekastit näin:..."

Et sitten huomannut mihkä viestiin tuolleen olin vastannut?

Kyse oli 1 taulu 10 näkymää VS 10 taulua.


Sinänsä koomista näinkin pienestä ja yksinkertaisesta asiasta kehkeytyy tämmöinen väittely. Kysy vaikka keneltä tietokanta gurulta niin minun ratkaisuni on parempa kuin sinun yhentaulun hömpsötys.

Lue lisää

>Kyse oli 1 taulu 10 näkymää VS 10 taulua.

Mitä jos ruotsinkieliselle sanoille päätetään lisätä sarake, missä on sanan suku (en/ett). Jos kaikki kielet ovat samassa taulussa, niin 10 kielen taulussa 95% sanoista saavat NULL arvon siinä sarakkeessa.

Tai sitten englanninkielisille sanoille Am./Br. jne...

Itse olen edelleen sitä mieltä, että pitäisi olla kieli per taulu.

(FileMaker Pro) kirjoitti:

"sinun ratkaisussasi ongelmaksi tulee se miten yhdistät tietyn sanan sen esimerkkiin. Toki kikkailemalla saat jotenkin toimivan."

Omat sovellukseni tosin yleensä toimivat "luonnollisella" struktuurilla (ilman eksplisiittistä IDtä), mutta toisinaan niitä tarvitaan. Ei liene "kikkailua" muodostaa relaatiolinkki vaikkapa tietueen numerolla tai millä tahansa "unique key" -arvolla?

Lue lisää

Unique ei oikein sovi sanakirjaan, kun samalla sanalla voi olla ei ainoastaan montaa selitystä, vaan sama sana voi olla eri sanaluokissa, esim:

kiinalainen (henkilö) - substantiivi
kiinalainen - adjektiivi

samoin nämä klassiset:

kuusi = puu (substantiivi)
kuusi = 6 (numeraali)

jne...

Silitys voi olla aika hauska, jos sanan "six" selityksenä on "puu joka kasvaa metsässä" :)

edellinen kirjoitti:

Unique ei oikein sovi sanakirjaan, kun samalla sanalla voi olla ei ainoastaan montaa selitystä, vaan sama sana voi olla eri sanaluokissa, esim:

kiinalainen (henkilö) - substantiivi
kiinalainen - adjektiivi

samoin nämä klassiset:

kuusi = puu (substantiivi)
kuusi = 6 (numeraali)

jne...

Silitys voi olla aika hauska, jos sanan "six" selityksenä on "puu joka kasvaa metsässä" :)

Lue lisää

Samoin ei ainoastaan sanaluokka, vaan myös eri merkitys samoilla sanoilla:

hiiri (substantiivi) - Eläin, hamsterin sukulainen
hiiri (substantiivi) - Tietokoneen oheislaite

edellinen kirjoitti:

>Kyse oli 1 taulu 10 näkymää VS 10 taulua.

Mitä jos ruotsinkieliselle sanoille päätetään lisätä sarake, missä on sanan suku (en/ett). Jos kaikki kielet ovat samassa taulussa, niin 10 kielen taulussa 95% sanoista saavat NULL arvon siinä sarakkeessa.

Tai sitten englanninkielisille sanoille Am./Br. jne...

Itse olen edelleen sitä mieltä, että pitäisi olla kieli per taulu.

Lue lisää

"Mitä jos ruotsinkieliselle sanoille päätetään lisätä sarake, missä on sanan suku (en/ett). Jos kaikki kielet ovat samassa taulussa, niin 10 kielen taulussa 95% sanoista saavat NULL arvon siinä sarakkeessa. Tai sitten englanninkielisille sanoille Am./Br. jne..."

Liitokset(joinit) ovat tietokannassa juurikin tuota varten.

Tuossa tapauksessa sanat tauluun ei kosketa ollenkaan. Vaan tehdään suku taulu varsinkin jos halutaan useille kielille lisätä tuo juttu.

Esim

sanat
sana_id | sana | kieli_id
1 | koira | 1
2 | tuoli | 1


suku
sana_id | suku | muuta_tietoa
1   | eläin | ihmisten lemmikki





Sitten vain kysely (MySQL) (Kysely on esimerkki siksi tähti..)
SELECT * FROM sanat LEFT JOIN suku USING(sana_id)

Palauttaa

1 | koira | 1 | eläin | ihmisten lemmikki
2 | tuoli | 1 | NULL | NULL




"Itse olen edelleen sitä mieltä, että pitäisi olla kieli per taulu."

Mielestäni on liioittelua tehdä joka kielellä oma taulu koska sanoja ei kuitenkaan tule olemaan niinpaljoa että tuosta saataisiin jotain etuja.

Viestis voi olla virheit kun kiireel kirjoitettu.

,,, kirjoitti:

"Mitä jos ruotsinkieliselle sanoille päätetään lisätä sarake, missä on sanan suku (en/ett). Jos kaikki kielet ovat samassa taulussa, niin 10 kielen taulussa 95% sanoista saavat NULL arvon siinä sarakkeessa. Tai sitten englanninkielisille sanoille Am./Br. jne..."

Liitokset(joinit) ovat tietokannassa juurikin tuota varten.

Tuossa tapauksessa sanat tauluun ei kosketa ollenkaan. Vaan tehdään suku taulu varsinkin jos halutaan useille kielille lisätä tuo juttu.

Esim

sanat
sana_id | sana | kieli_id
1 | koira | 1
2 | tuoli | 1


suku
sana_id | suku | muuta_tietoa
1   | eläin | ihmisten lemmikki





Sitten vain kysely (MySQL) (Kysely on esimerkki siksi tähti..)
SELECT * FROM sanat LEFT JOIN suku USING(sana_id)

Palauttaa

1 | koira | 1 | eläin | ihmisten lemmikki
2 | tuoli | 1 | NULL | NULL




"Itse olen edelleen sitä mieltä, että pitäisi olla kieli per taulu."

Mielestäni on liioittelua tehdä joka kielellä oma taulu koska sanoja ei kuitenkaan tule olemaan niinpaljoa että tuosta saataisiin jotain etuja.

Viestis voi olla virheit kun kiireel kirjoitettu.

Lue lisää

Et ole vielä kertonut miten sen "käännös liitos" taulun teet :)


Jatketaan esimerkkiä tästä:

Eli on 10 kieltä, ja pitäisi pystyä kääntämään jokaisesta kielestä mihin tahansa toiseen kieleen.

Sanat ovat luokissa (substantiivi, adjektiivi, verbi, jne..) koska sama sana voi olla useammassa luokassa (kiinalainen (henkilö) -substantiivi ja kiinalainen - adjektiivi)

Samoin sanat ovat eri ryhmissä (ATK, yleiskieli, kaupallinen, biologia, jne..) Koska samalla sanalla voivat olla eri merkitykset (hiiri - eläin ja hiiri - ATK-laite)

Sanoilla on myös selitykset (ei kaikilla).

Ja sitten pitäisi pystyä tehdä käännökset, esim jos kirjoittaa hakusanaksi "mouse" niin se palauttaisi seuraavat tiedot:

mouse - hiiri, substantiivi, biologia, "pieni eläin", englanti
mouse - hiiri, substantiivi, ATK, "tietokonelaite", englanti
mouse - en, mus, substantiivi, bilolgia, "ett litet djur", ruotsi
mouse - en, mus, substantiivi, ATK, NULL, ruotsi
jne...

,,, kirjoitti:

"Taannoin mekastit näin:..."

Et sitten huomannut mihkä viestiin tuolleen olin vastannut?

Kyse oli 1 taulu 10 näkymää VS 10 taulua.


Sinänsä koomista näinkin pienestä ja yksinkertaisesta asiasta kehkeytyy tämmöinen väittely. Kysy vaikka keneltä tietokanta gurulta niin minun ratkaisuni on parempa kuin sinun yhentaulun hömpsötys.

Lue lisää

"Kyse oli 1 taulu 10 näkymää VS 10 taulua.


Sinänsä koomista näinkin pienestä ja yksinkertaisesta asiasta kehkeytyy tämmöinen väittely. Kysy vaikka keneltä tietokanta gurulta niin minun ratkaisuni on parempa kuin sinun yhentaulun hömpsötys."

Eli siis sinulla oli yh(d)entaulun hömpsytys mielessäsi?

,,, kirjoitti:

"Ei liene "kikkailua" muodostaa relaatiolinkki vaikkapa tietueen numerolla tai millä tahansa "unique key" -arvolla?"

Ei, mutta mistä sinä tuon unique keyn muodostat tässä tapauksessa?

Sana ei käy koska käänös voi olla sama useilla kielillä.

Ilmeisesti teet sen näin
suomi, selite_suomi, ruotsi, selite_ruotsi...

Ja sitten jos tarttee lisää tietoja niin eikun lisää sarakkeita ja null arvoja vain.

Lue lisää

En yleensä pidä sellaisista, mutta jos esim. uudet tietueet saavat sarjanumeron, sillä voi hyvin linkittää esimerkit kaikille kielille.

(FileMaker Pro) kirjoitti:

"Kyse oli 1 taulu 10 näkymää VS 10 taulua.


Sinänsä koomista näinkin pienestä ja yksinkertaisesta asiasta kehkeytyy tämmöinen väittely. Kysy vaikka keneltä tietokanta gurulta niin minun ratkaisuni on parempa kuin sinun yhentaulun hömpsötys."

Eli siis sinulla oli yh(d)entaulun hömpsytys mielessäsi?

Lue lisää

"Eli siis sinulla oli yh(d)entaulun hömpsytys mielessäsi?"

Käsitit hieman väärin, kuten huomaat tuossa on kaksi väliä ja kommentoin sillä vain tätä väittelyä, joten tuo lainaamasi on kaksi eriasiaa. En ole missään vaiheessa sanonut että tämä sanakirja juttu kannattaisi tehdä yhdellä taululla, vaan että kaikki sanat yhteen tauluun ja sitten liitostaululla yhteen.


Mielestäni turha enään jatkaa tätä väittelyä sillä "(MySQL)" nimimerkille annoin toimivan ratkaisun.

,,, kirjoitti:

"Eli siis sinulla oli yh(d)entaulun hömpsytys mielessäsi?"

Käsitit hieman väärin, kuten huomaat tuossa on kaksi väliä ja kommentoin sillä vain tätä väittelyä, joten tuo lainaamasi on kaksi eriasiaa. En ole missään vaiheessa sanonut että tämä sanakirja juttu kannattaisi tehdä yhdellä taululla, vaan että kaikki sanat yhteen tauluun ja sitten liitostaululla yhteen.


Mielestäni turha enään jatkaa tätä väittelyä sillä "(MySQL)" nimimerkille annoin toimivan ratkaisun.

Lue lisää

Voisitko kuitenkin kertoa, miten tuolla "liitostaululla" saa käännökset yhteen jotenkin järkevästi. Ainakin minua jäi asia vaivamaan.

http://keskustelu.suomi24.fi/show.fcgi?category=108&conference=4500000000000137&posting=22000000020379093

Pitää viikonloppuna testata, kiitos !