opettelin sql:n (oleellisimman osan siitä) parissa viikossa työhön liittyvän tietokantasovelluksen vuoksi, eli se ei ole kovinkaan vaikeaa hallita. Ennen tuota tehtävää minäkän en tajunnut yhtään mitään tietokannoista (yhden TEORIAkurssin olen aiheesta aikoinani käynyt).
Harjoitustyön voi tehdä myös omalla koneella, mutta oikea SQL serveriympäristö on parempi vaihtoehto. (esim. Linux MySQL). Käyttöoikeuksia (user/group/all) ja käyttäjän tunnistamista ym. kannattaa hoitaa normaaliin tapaan linux-serverihallinnan puolella perl(?)-scripteillä.
0Äänestä
...
kehittävänsä ohjelmia, niin kannattaisi tajuta jotain tietokannoista, ja jos pitää tehdä tietokantaohjelmointia, niin sitten tulee osata SQL.
0Äänestä
SELECT *
jos ryhtyy johonkin laiteläheisempään tai muuten tekniikkaan liittyviin ohjelmistojen kanssa (tai Symbian). SQL on tosin aika helppo, joten jos se tuottaa vaikeuksia, niin ehkä paras pysyä myynti/manageri puolella.
0Äänestä
fhjksdfh
Jollei tietokannoista/tietovarastoista tajua mitään, ei kannata ajatella sovelluskehityksen tai suunnittelun hommia. Sopivat hommat taitaa olla tolla myyntipuolella, jossa tarvii muistaa vaan otsikot ja joskus ei sitäkään, ja tarvittaessa voi vaihtaa duunia ja ryhtyä myymään autoja.
0Äänestä
klemmareiden myyjä
ei tarvitse tietokantaosaamista lainkaan ict-alalla.
Ja vaikka osaisit kaiken kaikista tietokannoista, niin sekään ei takaa töitä kolmessa läänissäkään.
0Äänestä
ja osaamista
Huvittavia nuo kommentit, että sqln oppii kädenkäänteessä. Ne jotka sitä osaavat oikeasti tietävät, että sitä on montaa sorttia ja suorituskyky ja siirrettävyys tulee ottaa huomioon.
0Äänestä
riippuu usein
tietokantaan tallennetusta tiedosta, jonka jakaumaa hakuavaimen perusteella on usein mahdoton ennakoida, josta seuraa se, että tietokannan optimointi on jatkuvasti sisällöstä riippuvaa ja ajan mukaan muuttuvaa toimintaa.
Useimmiten tietokannan optimointia ei vaan huomioida, ellei kyse ole tuotannon kannalta kriittisestä transaktiosta/raportista.
Tietokannan nopeus/käytettävyys edellyttää yleensä ottaen normaalia työläämpää suunnittelu/ohjelmointivaihetta, jota ei alkuvaiheessa osata ottaa budjetissa huomioon.
Vastaukset 7
Vanhimmat
opettelin sql:n (oleellisimman osan siitä) parissa viikossa työhön liittyvän tietokantasovelluksen vuoksi, eli se ei ole kovinkaan vaikeaa hallita. Ennen tuota tehtävää minäkän en tajunnut yhtään mitään tietokannoista (yhden TEORIAkurssin olen aiheesta aikoinani käynyt).
Harjoitustyön voi tehdä myös omalla koneella, mutta oikea SQL serveriympäristö on parempi vaihtoehto. (esim. Linux MySQL). Käyttöoikeuksia (user/group/all) ja käyttäjän tunnistamista ym. kannattaa hoitaa normaaliin tapaan linux-serverihallinnan puolella perl(?)-scripteillä.
kehittävänsä ohjelmia, niin kannattaisi tajuta jotain tietokannoista, ja jos pitää tehdä tietokantaohjelmointia, niin sitten tulee osata SQL.
jos ryhtyy johonkin laiteläheisempään tai muuten tekniikkaan liittyviin ohjelmistojen kanssa (tai Symbian). SQL on tosin aika helppo, joten jos se tuottaa vaikeuksia, niin ehkä paras pysyä myynti/manageri puolella.
Jollei tietokannoista/tietovarastoista tajua mitään, ei kannata ajatella sovelluskehityksen tai suunnittelun hommia. Sopivat hommat taitaa olla tolla myyntipuolella, jossa tarvii muistaa vaan otsikot ja joskus ei sitäkään, ja tarvittaessa voi vaihtaa duunia ja ryhtyä myymään autoja.
ei tarvitse tietokantaosaamista lainkaan ict-alalla.
Ja vaikka osaisit kaiken kaikista tietokannoista, niin sekään ei takaa töitä kolmessa läänissäkään.
Huvittavia nuo kommentit, että sqln oppii kädenkäänteessä. Ne jotka sitä osaavat oikeasti tietävät, että sitä on montaa sorttia ja suorituskyky ja siirrettävyys tulee ottaa huomioon.
tietokantaan tallennetusta tiedosta, jonka jakaumaa hakuavaimen perusteella on usein mahdoton ennakoida, josta seuraa se, että tietokannan optimointi on jatkuvasti sisällöstä riippuvaa ja ajan mukaan muuttuvaa toimintaa.
Useimmiten tietokannan optimointia ei vaan huomioida, ellei kyse ole tuotannon kannalta kriittisestä transaktiosta/raportista.
Tietokannan nopeus/käytettävyys edellyttää yleensä ottaen normaalia työläämpää suunnittelu/ohjelmointivaihetta, jota ei alkuvaiheessa osata ottaa budjetissa huomioon.