Moi! Olen jo hetken aikaa painiskellut alla olevan koodin pätkän kanssa, eli siis sen pitäisi lisätä uusi taulu. En tiedä mitä olen tehnyt väärin, mutta toi ei vain toimi.
$kysely = $yhteys->prepare("CREATE TABLE {$vuosi} (id INT PRIMARY KEY AUTO_INCREMENT, paivamaara TEXT, elain TEXT, paikka TEXT, kaataja TEXT)");
$kysely = $kysely->execute();Mitä jos laittaisit Putkan oppaiden neuvojen mukaan virheilmoitukset näkyviin?
$yhteys->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); ini_set("error_reporting", E_ALL | E_STRICT); ini_set("display_errors", 1);
En nyt muista ulkoa, mutta luultavasti CREATE TABLE ei sovi preparen kanssa käytettäväksi, vaan pitää käyttää suoraan exec-metodia.
Ok, ei oikein antanut vastausat tohon ongelmaani.
Warning: Cannot modify header information - headers already sent by (output started at /Kotisivut/hirsistonmaja/indexulkoasu.css:255) in /Kotisivut/hirsistonmaja/Paivita.php on line 15
Rivillä 15 on seuraava koodi:
header("Location: Saalis");
Mutta tuon saaminen kuntoon ei ole ratkaisu sen kyselyn toimivuuteen, koska tämä kysely on ennen tuota headeria.
headers already sent -virheestä käydään kuukausittain keskustelua täällä. Miksei sitä voitaisi syöttää hakuun?
Virhe tarkoittaa, että olet tulostanut jotain sivulle ennen header-riviä. Korjaus: Poista kaikki tulostukset ennen header-riviä. Virheilmoituksessa on kerrottukkin, missä kohtaa virhe tulee.
Kyllä tuon pitäisi kai toimia koska taulun nimi määritellään queryssä suoraan, eikä ->execute():n sisällä parametrina. Olisko vika ettö taulun nimi on joku numero, esim 2011. Kokeile:
$taulu_etuliite = "t_";
$kysely = $yhteys->prepare("CREATE TABLE {$taulu_etuliite}{$vuosi} (id INT PRIMARY KEY AUTO_INCREMENT, paivamaara TEXT, elain TEXT, paikka TEXT, kaataja TEXT)");
$kysely = $kysely->execute();Lisäksi kannattaa kyllä miettiä vielä kerran että onko dynaamisten taulujen luonti varmasti tarpeellista, vai voiko kaikki taulut jo luoda ennen sovelluksen käyttöä.
makumaku kirjoitti:
Lisäksi kannattaa kyllä miettiä vielä kerran että onko dynaamisten taulujen luonti varmasti tarpeellista, vai voiko kaikki taulut jo luoda ennen sovelluksen käyttöä.
Tilanteesta enempää tietämättä voisin myös veikata, että kannattaisi lisätä tuo vuosiluku yhdeksi sarakkeeksi tauluun. Kannasta voi sitten kysyä helposti SELECT-lauseella tietyn vuoden sisältävät rivit.
Cornix kirjoitti:
Tilanteesta enempää tietämättä voisin myös veikata, että kannattaisi lisätä tuo vuosiluku yhdeksi sarakkeeksi tauluun. Kannasta voi sitten kysyä helposti SELECT-lauseella tietyn vuoden sisältävät rivit.
No ei kannata, vaan kannattaa kysellä vuoden mukaan suoraan päiväyksestä.
Teuro kirjoitti:
Cornix kirjoitti:
Tilanteesta enempää tietämättä voisin myös veikata, että kannattaisi lisätä tuo vuosiluku yhdeksi sarakkeeksi tauluun. Kannasta voi sitten kysyä helposti SELECT-lauseella tietyn vuoden sisältävät rivit.
No ei kannata, vaan kannattaa kysellä vuoden mukaan suoraan päiväyksestä.
Kas joo. Aivan.
Joo tosiaan kannattaisikin hakea päivämäärän mukaan samasta taulusta kaikkien vuosien hirvien kaadot.
Kannattaisi myös tehdä päivämäärästä DATE-tyyppinen.
Joo niin kannatta. Ja tohon headerin vielä sen verran, että ao. koodin lisääminen lopettaa ongelmat.
ob_start();
Jos tuo sovellus ei ole kovin pitkälle jo tehty, niin melkein ensin tosiaan kannattaa miettiä kokonaan tuo tietokantarakenne kuntoon. Eikä varmaan olisi paha asia vaikka sen heittäisi sitten tännekin kommentoitavaksi.
Myöskin tuo TEXT on varmaan aikalailla liikaa monien kenttien kohdalla, ja VARCHAR olisi optimaalisempi. Pitää miettiä kannattaako kaataja olla vain indeksillä, ja ne kaatajat sitten toisessa taulussa. Tietotyypit pitää valita tarkoituksen mukaan, eikä laittaa kaikkia TEXTiksi automaattisesti. Niinkuin sanottu, jos kaadoissa riittää pelkkä päivämäärä niin sen tyyppi on DATE. Mutta jos joskus pitää hakea tietoa että kuka kaatoi vuoden ensimmäisen hirven, niin silloin voidaan jo tarvita DATETIME tai TIMESTAMP tyyppiä, jos ajat merkitään vaikka tunnin tarkkuudella jne..
Joo, melko pitkällä se on, mutta se ei niin mahottoman suuri ole, etteikö sen voisi tehdä alusta asti uudelleen. Elikkäs kerronpa vähän tässä mikä on kyseessä. Sivu on hirvi porukkamme sivu. Tämä järjestelmä on sellainen, että admin 'tittelin' omistavat voivat aina käydä lisäämässä, kun on kaadettu hirvi.
Kun lisätään uusi kaato, niin siellä on kentät:
päivämäärä(muod. vvvv.kk.pp)
Paikka
sitten on kolme valintaa: Sonni, Vasa, Aikuiset naaraat
lopuksi vielä kaatajan nimi tulee.
Näistä tiedoista tärkeimmät ovat päivämäärä ja sitten eläin tyyppi. Muut saattavat olla tyhjiä. Aijassa ei tarvitse olla kellon aikaa.
Sivun yläosassa on linkki, josta pääsee lisäämään kaadon. Sen alapuolella on taulukko jossa on kaikki kauden kaadot. Taulukon alla on allekkain linkkejä, joissa on vuosilukuja, eli edellisten vuosien kaatoihin pääsee niistä.
Tätä systeemiä varten mulla on tietokannassa kaksi taulua: saalistilanne ja vuodet. http://imageshack.us/photo/my-images/402/tietokantarakenne.png/
Nyt jos taulukossa on 2010 vuoden kaadot, tämän linkin, josta pääsee lisäämään kaadon, tilalle tulee paino nappi, josta voi vaihtaa kautta. Se systeemi lisää tauluun vuodet vuoden 2011. Tätä vuodet taulukkoa käytän lähinnä siihen, että pystyn hakemaan siitä helposti kaikki edelliset vuodet.
Tämä nyt oli aika lailla sekavasti selostettu, mutta eiköhän siitä selvää saa..
En kyllä ihan ymmärtänyt että mihin tuota vuodet-taulua tarvitaan, minusta se on täysin turha. Sellainen tilanne vaan tulee mieleen että jos täytyy pitää kirjaa että minä vuosina on metsästystä harrastettu, niin vuodet-tauluun lisättäisiin tämä tieto, koska saalistilanne-taulusta sitä ei välttämättä näe jos mitään saalista ei ole tullut. Mutta tästä ei taida olla kyse.
Lisäksi kannattaa miettiä että kaikki seuran jäsenet laitetaan yhteen omaan tauluun, ja saalistilanne-tauluun vain id jäseneen. Jäsenet-taulussa minimissään id, nimi ja jäsenluokka (admin, normaali). Jos joka kerran pitää kaatajan nimi kirjoittaa erikseen on mahdollista että samalle henkilölle sinne tulee nimeksi, Seppo Kaartinen, Seppo Kartinen, Kaartinen Seppo, jne...
Sama koskee tuota eläinten valintaa. Eri valinnat pitaisi olla tarkkaan yksilöllisesti määriteltyjä, eikä vain pelkkää tekstiä. Muuten voi olla hankalaa luotettavasti hakea tietoa että montako vasaa on kaadettu vaikka vuosina 2010-2020, tai sitten tämä pitäisi jotenkin hoitaa koodin puolella.
hmm. Periaatteessa sillä pidetään kirjaa niistä vuosista, jolloin on metsästetty, mutta ei minään vuonna ole käynyt niin, että kun on metsästetty, että oltaisiin jääty ilman hirviä.
Tuo jäsen taulu ehdotus on ihan käypä, tosi joutuisin kirjaamaan käsin kaikki ne tiedot, mutta se vaiva ehkä kannaattaa ottaa.
Eläinten valinnassa siis on kolme radio buttonia, joista valitaan se kaadettu eläin, joten se teksti on jokaisessa samssa eläimessä sama, jos sitä meinasit.
dartvaneri kirjoitti:
hmm. Periaatteessa sillä pidetään kirjaa niistä vuosista, jolloin on metsästetty, mutta ei minään vuonna ole käynyt niin, että kun on metsästetty, että oltaisiin jääty ilman hirviä.
Käytännössä kaikki kaadot voidaan tallentaa yhteen ja samaan tauluun. Yksi taulu riittää, haettiin sitten kaikkia kaatoja välillä 1900 ... 2011, tai sitten vain vuotta 2010, tai vaikka kauden ensimmäistä kaatoa vuosittain.
Ehdottomasti Teuron (ja muidenkin) neuvojen mukaan kaikki kaadot yhteen(!!) tauluun. Tietokannat ovat juuri tehty tälläisiä tietoja varten, eli älä yritä keksiä pyörää uudelleen.
Päivämäärät vielä tietokannan omaan muotoon, niin niiden järjestely ja rajailu onnistuu oletuksena oikein.
Se, että ihmissilmälle tietoa voi olla yhdessä taulussa paljon, ei tarkoita, että se olisi koneelle jotenkin pelottavaa.
Lebe80 kirjoitti:
Ehdottomasti Teuron (ja muidenkin) neuvojen mukaan kaikki kaadot yhteen(!!) tauluun. Tietokannat ovat juuri tehty tälläisiä tietoja varten, eli älä yritä keksiä pyörää uudelleen.
Päivämäärät vielä tietokannan omaan muotoon, niin niiden järjestely ja rajailu onnistuu oletuksena oikein.
Se, että ihmissilmälle tietoa voi olla yhdessä taulussa paljon, ei tarkoita, että se olisi koneelle jotenkin pelottavaa.
Ja siinä vaiheessa kun tietoa alkaa olla koneellekin paljon, astuvat kuvaan lisäoptimoinnit kuten indeksien tai "välimuistitaulujen" käyttö. Ei riitä yhden metsästysklubin mullikoiden maailmanhistorian kirjaaminen siihen, että kunnolla tehty tietokanta alkaisi yskähdellä.
Teinpä kokeeksi 4-taulua simuloimaan kaatoja. Yhdessä taulussa oli henkilöt (id, etunimi, sukunimi, puhelin, seura. Toisessa oli hirvien tyypit (id, tyyppi). Kolmannessa oli seurat (id, nimi). Viimeisessä taulussa oli kaadot (id, aikaleima, kaataja, tyyppi).
Generoin 3-seuraa, 500-henkilöä, ja 20000-kaatoa. Eli varmaankin roimasti yläkanttiin, mutta siitä huolimatta haut toimivat aivan riittävän nopeasti. mitään optimointeja ei tehty, eikä niille ole luultavasti mitään tarvettkaan.
Juu, kiitos ehdotuksista, ja näistä olisi tarkoitus sitten tehdä, ei yrittää tehdä, se systeemi. Mutta niin, mulla on käyttäjät taulu myös, koska jäsenet voi rekisteröityä sinne. Tosin en voi käyttää sitä taulua, koska kaikki(mm. iäkkäät jäsenet) jäsenet eivät rekisteröidy siine, joten joutuisin tekemään uuden taulun sinne, mutta onko tässä sitten mitään järkeä, koska se kaataja ei nyt niin tärkeä olekkaan, vaikka olisikin erilailla kirjoitettu, mutta kannataako se varalta tehä, jos joskus sitten tarvitsee?
dartvaneri kirjoitti:
Tosin en voi käyttää sitä taulua, koska kaikki(mm. iäkkäät jäsenet) jäsenet eivät rekisteröidy siine, joten joutuisin tekemään uuden taulun sinne
Perusteles tätä nyt vielä hiukan. Miten niin iäkkäät eivät voi käyttää taulua?
Mikset voi lisätä niitä iäkkäitä jäseniä sitten itse? Hölmöä olisi monella taululla kikkailla.
Noh tarkemmin ajatellen ne voisi laitta, mutta silloin täytyy tehdä kenttä, jossa on merkintä rekisteröitymisestä.
Tai sitten jätät esimerkiksi salasanasarakkeen heiltä tyhjäksi.
Aihe on jo aika vanha, joten et voi enää vastata siihen.
