Keskustelu: Nettisivujen teko: Tiedon laskeminen

Hei!

Ennenkuin aloitan toteuttamaan mitään niin ajattelin tiedustella olisiko teillä antaa järkevää toteutus näkökulmaa.

Minulla on kalenteri jota voi täyttää määrätyillä kirjaimilla, kuten L,M,N,O

Ajatellaan, että kalenteriin liitetään vaikka viisi henkilöä, kuukausia on 12, päiviä satuunaisesti 28-31. Miten tieto olisi järkevin tallentaa.

(12 * 31) * 5 on monta kenttää tietokantaan jos sille linjalle lähtisi.

Jos taas tekisi yhden kentän per henkilö/kuukausi johon nakkaisi arvot implodella niin miten siitä voisi laskea ESIM kaikki L kirjaimet sekä tyhjät kentät?

||L|||L||||

Vai olisiko vielä jotain järkevämpää toteutusta vinkata?

manninen kirjoitti:

Ajatellaan, että kalenteriin liitetään vaikka viisi henkilöä, kuukausia on 12, päiviä satuunaisesti 28-31. Miten tieto olisi järkevin tallentaa.

(12 * 31) * 5 on monta kenttää tietokantaan jos sille linjalle lähtisi.

Eihän tuo 12 * 31 * 5 eli 1860 ole vielä mitään, kyllä tietokantaan voi hyvin laittaa noin monta riviä.

Itse lähtisin toteuttamaan siten, että tauluun tulisi esim. kentät:
id (kuten aina), päiväys, henkilö ja valittu.

Tietenkin jos voi valita monta, niin parin taulun ratkaisu:
päivät: id, päiväys
valinnat: id, päivä_id, henkilö, valittu
Valinta sitten tapahtuisivat jotenkin tähän tyyliin:

SELECT * FROM päivät, valinnat WHERE päivät.id = valinnat.päivä_id AND henkilö = (mitä itse haluatkin)

-tossu kirjoitti:

Eihän tuo 12 * 31 * 5 eli 1860 ole vielä mitään, kyllä tietokantaan voi hyvin laittaa noin monta riviä.

manninen tarkoitta kenttiä, ei rivejä (tai näin hän ainakin sanoi)

Kyllä, tarkoitan kenttiä.

Onko nuo kirjaimet L,M,N,O jonkinlaisia varauksia joillekin päiville?
Ilmeisesti suurin osa päivistä on kuitenkin täysin tyhjiä? Ei kai ole mitään järkeä tallettaa tietoa että jonakin päivänä ei ole mitään tapahtumaa, tallettaa vain ne tapahtumat.

Joka tapauksessa ei kannata alkaa tekemään mitään pitkiä merkkijonoja joihin jollakin systeemillä yhdistellään varauksia/tapahtumia, ja sitten niitä joudutaan purkamaan auki. Tavoite (tarkemmin tietämättä käyttötarkoitusta) olisi että jokainen yksilöllinen varaus talletetaan omata tapahtumanaan tietokantaan.
Sitten jos sinulla tulee tietokantaan rivejä luokkaa miljoona niin voi miettiä että pitääkö optimoida jotakin, kun puhutaan kymmenistä tuhansista riveista (tapahtumista) niin se ei määränä ole vielä yhtään mitään.

EDIT: ai, nuo kentät oli tosiaan kenttiä eikä rivejä :o

Jotain tämmöistä:

create table kayttaja (
  id integer primary key,
);

create table tapahtumatyyppi (
  id integer primary key,
  nimi varchar(255),
);

create table tapahtuma (
  id integer primary key,
  nimi varchar(255),
  pvm  date,
  tyyppi integer references tapahtumatyyppi,
);

create table osallistuja (
  id integer primary key,
  osallistuja references kayttaja,
  tapahtuma references tapahtuma,
);

Tietty ihan en päässyt jyvälle, mitä tarkkaan ottaen olet tallentamassa kalenteriin. Tuolla siis voi tallennella tapahtumia, joiden tyypit on lookup-taulussa (tapahtumatyyppi). Tapahtumiin sitten voi liittää käyttäjiä assosiaatio-taulun avulla (osallistuja).

Tyhjiä päiviä ei liene järkevää etukäteen tallentaa tietokantaan vain generoida ne tarvittaessa käyttöliittymään.

Ei niitä kannata kenttinä tehdä, jos tietokanta on käytössä. Tallentaa vain rivitietoina, jolloin rivillä pitäisi olla ainakin päivämäärä, ja henkilön id. Id tässä tapauksessa vastaisi tietokannan henkilö-taulun henkilön yksilöivä id. Jos jotain lyhenteitä haluat, niin laita henkilöille omat lyhenteet, haluamassasi muodossa tietenkin, olkoon ne yksittäisiä kirjaimia, hex-värejä tai vaikkapa jamppojen naamakirjan kuvien urleja.

edit:
Lanu kerkisikin jo kirjoittaa väliin...

Kiitoksia, kiitoksia. Nyt välähtikin sen verran, että tiedänhän minä tosiaan mistä kuukaudesta on kyse.

Tyhjät merkinnät tarkoittivat, että on paikalla siksi olisin ne kantaan halunnut. Mutta kun tiedän kuukauden niin eihän minun tarvitse vähentää siitä kuin poissaolo, silloin tiedän vastauksen läsnäoloon ;)

Thanks..

manninen kirjoitti:

Tyhjät merkinnät tarkoittivat, että on paikalla siksi olisin ne kantaan halunnut. Mutta kun tiedän kuukauden niin eihän minun tarvitse vähentää siitä kuin poissaolo, silloin tiedän vastauksen läsnäoloon ;)

Niin, tuo minun ehdotus oli siltä pohjalta että kyse on jonkinlaisesta tapahtumakalenterista. Työvuorolistalle saattaa olla parempiakin rakenteita.

Idea säilyy kuitenkin samana, missään nimessä ei kannata lähteä lisäämään sarakkeita. Normaalimuotojen selitykset on yleensä aika akateemisia. Tuolla linkin takana niitä avataan varsin onnistuneesti. Edit: Tai siis tuolla kerrotaan normalisoinnin abc kertomatta normalisoinnista yhtään mitään :-)

Itse varmaan toteuttaisin ihan vain laittamalla tietokantaan yhden taulun.

Jos voi olla vain joku noista kirjaimista niin

henkilö_id, päiväys, kirjain

Ja jos voi laittaa vaikka kaikki kirjaimet samalle päivälle ja samalle henkilölle niin

henkilö_id, päiväys, l, m, n, o ja ykkösiks ne kirjaimet jotka on valittu (ehkä nuo voisi nimetä järkevämmin)

ja varaustapahtuma
INSERT INTO taulu (henkilö_id, päiväys, l, m, n, o) VALUES('1337', 'unixtimestamp tai päivämäärä', '1', '0', '1', '0');