Sql tietokannan suunnittelu. Minulla on 2 Sql taulua yhdessä rekisteröityneet käyttäjät. Toisessa taulussa käyttäjien tallentamaa tietoa. Haettu tieto on yksilöllistä eli näkyy vain käyttäjä kohtaisessa näkymässä. Pitäisikö jokaisella käyttäjällä olla oma taulu mihin tieto tallennetaan vai onko tämä malli oikea?
Yleensä tyypillinen malli on, että tietotaulussa on sarake (ja vierasavain eli foreign key), joka viittaa tuohon käyttäjät tauluun.
Pistä käyttäjätauluun vaikka käyttäjän id. Toisessa taulussa sitten kaikki ja tuo käyttäjän id. Haussa palautat vaan relevantin tiedon tuon toisen id:n perusteella.
mitä jos taulu 2 onkin iso esim 300 tuhatta saraketta. Onko edelleen järkevää suorittaa haku id,n perusteella vai syökö se liikaa tehoja palvelimelta verrattuna siihen, että jokaisella käyttäjällä olisi oma taulu?
Jos taulussa on 300 000 saraketta, niin se on ihan päin persettä suunniteltu. En edes tiedä yhtään tietokantamoottoria, joka tukisi noin montaa saraketta.
Ehkä tarkoitit kuitenkin rivejä. Useimmissa tietokantamoottoreissa 1000 erillistä taulua joissa keskimäärin 300 riviä veisi enemmän tehoja kuin yksi taulu jossa 300 000 riviä ja (indeksoitu) vierasavain. Lisäksi erilaisissa työkalujeissa (esim. ORMit) ei välttämättä ole tukea tuollaisille dynaamisille tauluille.
Heh,
Juu siis rivejä tarkoitin. Okei, eli jatkan tällä alkuperäisellä suunnitelmalla yhdestä taulusta kootaan tiedot jokaiselle käyttäjälle erikseen foreign keytä hyödyntäen.
Silti mietityttää miten se SQL foreign haku alkoritmi voi olla niin tehokas, että se pystyy nopeasti käymään satojatuhansia tietoja läpi.
Kiitos vastauksista.
Joo siis olennaista haun nopeudessa ei ole se vierasavain sinänsä vaan indeksointi.
Sinänsä jos tarpeesi ei ole nyt eikä koskaan myöhemminkään muu kuin hakea tietyn yhden käyttäjän tietoja kerrallaan, niin erilliset taulut voisi ihan puhtaasti tehomielessä olla parempi.
Yleensä kuitenkin on tilanteita, joissa halutaan hakea useampia käyttäjiä koskevia tietoja. Jos esimerkiksi haluttaisiin hakea tieto ketkä käyttäjät viimeksi ovat tallentaneet tietoa niin erillisten taulujen tapauksessa pitäisi tehdä kysely joka hakee tietoa jokaisesta taulusta ja tällaiset sitten söisi melko tehokkaasti sen pienen tehosäästön mikä yksittäisten käyttäjien tietojen haussa voitaisiin saavuttaa.
Yksi relaatiotietokannan suunnitteluperusteista on, että tietokannan rakenteen (taulut) ei pitäisi muuttua, kun tietokantaan lisätään tietoa. Jos tästä suunnitteluperiaatteesta poiketaan niin siihen pitäisi olla joku poikkeuksellisen painava syy.
Rupesin tossa miettimään, että olisi käyttäjälle mukavempaa jos tieto mikä on tallennettu olisi katekorioissa esim. Päivämäärän tai tallennetun tiedon nimen mukaan.
Eli tarvisikin olla 3 taulua
1) Käyttäjät
2) katekoriat (Nimi, Päivämäärä)
3) Tallennetut tiedot
Menisikö tämä jotenkin niin, että käyttäjistä pointataan id;llä kaikkiin käyttäjän tallentamiin katekorioihin, ja sitten katekoria taulu pointtaa tallennettuihin tietoihin. Nimellä ja päivämäärällä. Mitä jos nimi ja päivämäärä onkin kahdella käyttäjällä sama. Ei taida toimia.
Katekoria taulussa pitäisi olla myös id joka pointtaa tallennettuihin tietoihin. Vai meneekö mietintäni taas ihan metsään?
Miksi nimi pitää tallentaa? Id on yksilöivä tieto, eikä kellään toisella käyttäjällä voi olla samaa id:ä (jos puhutaan siis yksilöivästä id:stä, kaikenlaiset muut tunnisteet on toisarvoisia).
Jos tallennat nimen johonkin muuhunkin tauluun, niin mitä jos käyttäjän nimi muuttuu myöhemmin?
Lebe80
Tarkoitin siis, että käyttäjä nimeää itse tallennetun tiedon. Esim Kissa kuvat.
Siis käytännössä se menis niin että tallennettu tieto taulussa on sarake "käyttäjäId" ja sarake "kategoriaId" ja nämä viittaavat siis vastaavasti käyttäjä- ja kategoria-tauluihin.
Jos kategorioiden on tarkoitus olla käyttäjäkohtaisia (käyttäjien syöttämiä) niin sitten tietenkin myös kategoria -taulussa voi olla "käyttäjäId" -sarake joka viittaa käyttäjät -tauluun.
Nää on ihan "relaatiotietokannan perusteet" juttuja.
Grez joo ihan siis perus juttuja tässä opettelenkin.
Aihe on jo aika vanha, joten et voi enää vastata siihen.