SQL Ohjelmointi?
Jorma Hongisto
vaatii?
Samoin millä ohjelmistoilla sitä voidaan toteuttaa?
Olisiko esimerkkejä?
Pete
3dol...@nic.fi
jom...@iki.fi
> Kertoisiko joku ystävällinen mitä on SQL ohjelmointi tai mitä sen osaaminen
> vaatii?
Vähän sama, kun joku kysyisi "mitä on PS-ohjelmointi". Eli SQL on kieli,
jolla kysytään (relaatio)tietokannasta tietoja (Structured Query
Language).
Suomeksikin on aiheesta ilmestynyt kirjoja.
> Samoin millä ohjelmistoilla sitä voidaan toteuttaa?
Tietokantaohjelmistoilla (esim. access, MySQL) tai tietokantarajapintojen
(esim. ODBC) avulla lähes millä tahansa ohjelmointikielellä.
> Olisiko esimerkkejä?
SELECT * FROM taulut WHERE id=3;
--
Sine spe vita tristis esset
Tero Markus Ronkko
>Kertoisiko joku ystävällinen mitä on SQL ohjelmointi tai mitä sen osaaminen
>vaatii?
>Samoin millä ohjelmistoilla sitä voidaan toteuttaa?
SQL on structured query language, eikä oikeastaan ole ohjelmointikieli
vaan kyselykieli jolla voi suorittaa 'kyselyjä' tietokantaan.
Tietokannoilla sitä voi 'toteuttaa'.
>Olisiko esimerkkejä?
Select * from sql.faq;
commit;
Laita hakusanaksi SQL tutorial vaikkapa altavistassa.
--
Beauty: That power by which a woman charms a lover and terrifies a
husband.
Ambrose Bierce: The Devil's Dictionary {Men and Women}
Jori Mantysalo
> Kertoisiko joku ystävällinen mitä on SQL ohjelmointi
Relaatiotietokanta koostuu tauluista, joiden kentät voivat olla vaikka
nimi - sukupuoli - kunta
kunta - maa
ja SQL on kyselykieli, jolla haettaisiin esimerkiksi jokainen mies, joka
asuu Suomessa. Relaatiotietokannan idea on siinä, että tietoa ei jouduta
muuttamaan kuin yhteen paikkaan. Jos esimerkiksi Ruotsi hyökkää ja
valloittaa Tampereen, niin riittää muuttaa rivi "Tampere - Suomi"
muotoon "Tampere - Ruotsi", eikä tarvitse tehdä satoja muutoksia
"Jori - Tampere - Suomi" --> "Jori - Tampere - Ruotsi",
"Ville - Tampere - Suomi" --> "Ville - Tampere - Ruotsi" jne.
Tietokannoista löytyy lisätietoa esim. seuraamalla sivun
http://www.cs.uta.fi/~av/tiko/
linkkejä. Myös tämä kannattaa katsoa:
http://www.dmoz.org/Computers/Programming/Languages/SQL/
--
= = = = Jori Mäntysalo - jm5...@uta.fi = = = =
"Lukiko siinä 'nainen ei ole pelkkä seksikone?' Jos siitä puuttui se
pelkkä-sana, niin se oli täyttä puppua.
-- Krista Salonen
Markku Uttula
>> Olisiko esimerkkejä?
>
> SELECT * FROM taulut WHERE id=3;
SELECT aloittelija FROM sfnet.atk_ohjelmointi WHERE asiantuntemus LIKE '0%';
UPDATE sfnet.atk_ohjelmointi SET aloittelija = 'viisastunut' WHERE
asiantuntemus LIKE '5%';
--
Markku Uttula
Antti S. Brax
> SELECT aloittelija FROM sfnet.atk_ohjelmointi WHERE asiantuntemus LIKE '0%';
> UPDATE sfnet.atk_ohjelmointi SET aloittelija = 'viisastunut' WHERE
> asiantuntemus LIKE '5%';
Vaikka kyse on vittuilusta, niin voisit edes yrittää ylläpitää
jonkinlaista kuvaa ammattitaidosta.
--
/"\
\ / ASCII RIBBON CAMPAIGN Antti S. Brax - a...@iki.fi
X AGAINST HTML MAIL Old school
/ \ (AND NEWS TOO, dammit) http://www.iki.fi/asb/
Markku Uttula
> Markku Uttula <markku...@perlanet.fi> wrote in sfnet.atk.ohjelmointi:
>> SELECT aloittelija FROM sfnet.atk_ohjelmointi WHERE asiantuntemus LIKE
'0%';
>> UPDATE sfnet.atk_ohjelmointi SET aloittelija = 'viisastunut' WHERE
>> asiantuntemus LIKE '5%';
>
> Vaikka kyse on vittuilusta, niin voisit edes yrittää ylläpitää
> jonkinlaista kuvaa ammattitaidosta.
Tuota... Jätit lainauksestasi pois sen rivin, jolla esimerkkejä pyydettiin.
Kyseessä ei missään tapauksessa ollut vittuilu, vaan elävän elämän esimerkki
kahdesta erilaisesta SQL-lauseesta (SELECT- ja UPDATE-lauseesta). Syy
siihen, miksi en vastannut suoraan kysyjälle on, ettei nyytistimeni
näyttänyt hänen viestiään (vaan ainoastaan siihen lähetetyn vastauksen) kun
lähetin viestini (nyt kyllä näkyy jo - mielenkiintoisia omituisuuksia
OE:ssa).
Ammatitaidon suhteen toki tuossa on pienoinen rike
relaatiotietokanta-ajattelun suhteen (eli mikäli aloittelija-soluun ei
kannata tallentaa osaamistasoa kuvaavaa tekstidataa vaan viittaus toiseen
tauluun ID:llä, jossa tekstinpätkät on määritelty). Syntaktisestihan nuo
ovat täysin valideja SQL-lauseita, vai kuulenko eriäviä mielipiteitä? Haluan
myös huomauttaa, että joissakin SQL-moottoreissa on auto-commit, jolloin
sitäkään ei tarvita tuonne update-lauseen jälkeen.
--
Markku Uttula
Aki Rossi
> OE:ssa).
"Get Next Headers" tarpeeksi monta kertaa niin kyllä se sieltä putkahtaa.
-Aki
Jussi Kallioniemi
> Vähän sama, kun joku kysyisi "mitä on PS-ohjelmointi". Eli SQL on kieli,
> jolla kysytään (relaatio)tietokannasta tietoja (Structured Query
> Language).
Aina silloin tällöin herää keskustelua aiheesta, onko SQL
ohjelmointikieli vai ei.
Postscriptilla, johon tuossa viitattiin, ainakin on tehty kohtuullisen
pervoja viritelmiä, ohessa esim. possu, joka renderöi pari hianoa palloa
- kokoa huimat 706 byteä. Varoituksen sana: tuon tulostaminen kestää
KAUAN :)
Mutta, voisiko joku, joka väittää että SQL on oikea ohjelmointikieli,
antaa viitteeksi edes about "ANSI" SQL:ää olevan pätkän joka tekisi
jotain edes hieman sivistyneemmän/monimutkaisemman ohjelman kaltaista.
Proseduurit ovat tietysti asia erikseen, ainakin joidenkin
tietokantamoottoreiden ohjelmointikielillä voi tehdä hyvinkin
monimutkaista ohjelmallista logiikkaa.
Nyt haussa olisi siis ihan plain SQL, jota kehtaat väittää "ohjelmaksi".
--klippa här, postscriptia--
%!IOPSC-1993 %%Creator: HAYAKAWA Takashi<xxxx...@xx.xxxxxx.xx.xx>
/C/neg/d/mul/R/rlineto/E/exp/H{{cvx
def}repeat}def/T/dup/g/gt/r/roll/J/ifelse 8
H/A/copy(z&v4QX&93r9AxYQOZomQalxS2w!!O&vMYa43d6r93rMYvx2dca!D&cjSnjSnjjS3o!v&6A
X&55SAxM1CD7AjYxTTd62rmxCnTdSST0g&12wECST!&!J0g&D1!&xM0!J0g!l&544dC2Ac96ra!m&3A
F&&vGoGSnCT0g&wDmlvGoS8wpn6wpS2wTCpS1Sd7ov7Uk7o4Qkdw!&Mvlx1S7oZES3w!J!J!Q&7185d
Z&lx1CS9d9nE4!k&X&MY7!&1!J!x&jdnjdS3odS!N&mmx1C2wEc!G&150Nx4!n&2o!j&43r!U&0777d
]&2AY2A776ddT4oS3oSnMVC00VV0RRR45E42063rNz&v7UX&UOzF!F!J![&44ETCnVn!a&1CDN!Y&0M
V1c&j2AYdjmMdjjd!o&1r!M){( )T 0 4 3 r put
T(/)g{T(9)g{cvn}{cvi}J}{($)g{[}{]}J}J
cvx}forall/moveto/p/floor/w/div/S/add 29 H[{[{]setgray fill}for Y}for
showpage
--klippa här, postscriptia--
-- Jussi Kallioniemi
Jussi Kallioniemi
Jos tuo postscripti kiinnosti, nii laitoin sen tyrkylle
-> http://www.cyberian.org/raytrace.ps
-- Jussi
Markku Uttula
> Varoituksen sana: tuon tulostaminen kestää KAUAN :)
03:50:45 NT:n CPU-aikaa 72dps tarkkuuteen. CPU-kuorma kaiken aikaa 90%
paremmalla puolella (=koneella ei juuri tehdä muuta sinä aikana).
Kieltämättä mielenkiintoinen viritys eikä lainkaan pöhkömpi kuvakaan
loppujen lopuksi. Varsinkin kun ottaa huomioon vaaditun koodin määrän.
--
Markku Uttula
Antti S. Brax
> relaatiotietokanta-ajattelun suhteen
Se on suurinpiirtein suurin rike, jonka tietokantasuunnittelussa
voi tehdä. Tietokantasuunnittelun ensimmäinen sääntö on, että
samaa dataa ei ikinä talleteta kahteen paikkaan. Miksi myös tal-
letat selkeät lukuarvot merkkijonoina? Tuon järjettömyys pitäisi
tajuta jo kun katsoo WHERE-lauseen LIKE-kludgetusta. Ja sfnet.-
atk_ohjelmointi on mahtavan epälooginen nimi taululle, jossa
säilytetään uutisryhmän lukijatietoja.
Jani Tiainen
>
> In article <L3hd6.85$Jo1....@uutiset.nic.fi>, Jorma Hongisto wrote:
>>Kertoisiko joku ystävällinen mitä on SQL ohjelmointi tai mitä sen osaaminen
>>vaatii?
>>Samoin millä ohjelmistoilla sitä voidaan toteuttaa?
>
> SQL on structured query language, eikä oikeastaan ole ohjelmointikieli
> vaan kyselykieli jolla voi suorittaa 'kyselyjä' tietokantaan.
> Tietokannoilla sitä voi 'toteuttaa'.
Tähänhän on sitten ainakin PL/SQL olemassa, Microsoftilla ja Sybasella
T-SQL.
Tietenkin pelkkä SQL sisältää vain joukon käskyjä joilla voidaan tehdä
kyselyjä (mutkikkaitakin sellaisia).
>>Olisiko esimerkkejä?
Pistetäänpäs kivan kompleksinen kysely näkyviin, eikä toi edes
monimutkainen ole...
select m.name || ' ' || mv.version_name "MODULENAME",
mv.id "ID" from kr_module m, kr_module_version mv,
kr_application_module_version amv where
mv.module_id = m.id and amv.application_version_id = appversion.id and
amv.module_version_id = mv.id order by mv.version_name
--
- ReDe
"Osaan asioita joita en ole vielä edes oppinutkaan!"
Markku Uttula
"Antti S. Brax" wrote...
> Miksi myös talletat selkeät lukuarvot merkkijonoina?
Mistä päättelet kyseessä olevan lukuarvojen? LIKE '5%' täsmää mm. '50',
'5a', '5SFS-67ER' sekä monta muuta.
> Ja sfnet.atk_ohjelmointi on mahtavan epälooginen nimi
> taululle, jossa säilytetään uutisryhmän lukijatietoja.
Nyt teet päätelmiä taulusta ja solujen sisällöistä tuntematta lainkaan
taulun rakennetta. Myönnettävä kuitenkin on, että minun on joskus vaikea
pitää turpaani kiinni kun joku (tuntematon) kommentoi ammattitaitoa (joko
omaani tai työtovereideni). Lisäksi väsymys verottaa kovasti jo tässä
vaiheessa päivää.
Mahtaako seuraava esimerkki tyydyttää lainkaan aikaisempia enempää?
select
avg(value)
from
mu.person_knowledge a,
mu.user_info b,
mu.organisation c,
mu.knowledge d
where
value is not null and
a.person_id = b.user_id and
b.organisation_group_id = c.organisation_id and
c.level_id_2 = l_organisation_id and
a.knowledge_id = d.knowledge_id and
d.level_id_2 = l_level_id;
Ja vaikkei se asiaan (eli esimerkkien antamiseen) lainkaan liitykään, otin
tuosta jo sen verran selvää, että tuolla tavalla liitettynä ratkaisu saadaan
nopeammin kuin tekemällä alikyselyjä tyyliin mu.person_knowledge.person_id
in (select * from mu.user_info.user_id) jne.
--
Markku Uttula
Antti S. Brax
Sitähän tässä on tehty jo pitkän aikaa. ;-)
> "Antti S. Brax" wrote...
> > Ja sfnet.atk_ohjelmointi on mahtavan epälooginen nimi
> > taululle, jossa säilytetään uutisryhmän lukijatietoja.
>
> Nyt teet päätelmiä taulusta ja solujen sisällöistä tuntematta lainkaan
> taulun rakennetta.
Ha! Jos olet yhtään ohjelmointioppaita lukenut, niin niissä
sanotaan, että muuttujille/luokille/etc. rakenteille pitää
valita nimet, jotka kuvaavat niiden tarkoitusta ja sisältöä.
Nimi "sfnet.atk_ohjelmointi" antaa olettaa, että taulu pi-
tää sisällään uutisryhmän tietoja. Siinä ei millään tavalla
anneta ymmärtää, että siellä olisi tietoa myös lukijoista.
Ja koska lukija ja uutisryhmä ovat selkeästi erilliset asiat
(joiden välillä on subscribe-relaatio) niin nehän laitetaan
omin tauluihinsa. Eikö?
> Mahtaako seuraava esimerkki tyydyttää lainkaan aikaisempia enempää?
> from
> mu.person_knowledge a,
> mu.user_info b,
> mu.organisation c,
> mu.knowledge d
A, b, c, d? Onpa hyvin valitut aliakset... ;-P
Jussi Kallioniemi
FROM UNNews_Users, UNNews_AuthorProfiles, UNNews_Articles
WHERE
UNNews_AuthorProfiles.Whinepoints > 98 AND
UNNews_Articles.timestamp between (42424242 and 980856271) AND
UNNews_Articles.mid not in ('3A766BE8...@teraflops.com',
'3A766D0B...@teraflops.com') AND
AND UNEWS_Articles.group = "sfnet.atk.ohjelmointi";
ORDER BY PNUSSIJA
COMMIT WORK;
QUIT;
Joo. Tosiaan esim. solidin moottoria käyttäessä kannattaa kommitoida
myös selectit :)
-- Jussi Kallioniemi
Jusa Juutilainen
Markku Uttula <markku...@perlanet.fi> wrote:
>Mahtaako seuraava esimerkki tyydyttää lainkaan aikaisempia enempää?
Ehdottomasti paremman näköinen kuin aikaisempi. Muutamia (turhia)
pointteja kuitenkin.
>
> select
> avg(value)
Mistä taulusta kenttä "value" haetaan? Olen itse todennut
selventäväksi mainita aina mistä ollaan hakemassa. (Hypoteettisesti se
voi olla myös SQL-parserille kevympää, tietääkö kukaan?)
> from
> mu.person_knowledge a,
> mu.user_info b,
> mu.organisation c,
> mu.knowledge d
Itsekin monasti käytän kirjainaliaksia, kuitenkin siten että
kirjaimista näkee suoraan kuinka olen ajatellut liitoksen
menevän. Tässä on ilmeisesti tehty samalla tavoin.
> where
> value is not null and
Avg-funktio jättää kyllä null arvot laskematta eli ei tätä tarvitse
välttämättä mainita. Tietysti joskus voi olla suorituskyky etua
mainita. Tästäkään ei käy esille missä taulussa value majailee.
> a.person_id = b.user_id and
> b.organisation_group_id = c.organisation_id and
> c.level_id_2 = l_organisation_id and
> a.knowledge_id = d.knowledge_id and
> d.level_id_2 = l_level_id;
No sen enempää miettimättä näyttää ihan asiallisesta ja normaalilta
liitosehdotelmalta. Näkisin tässäkin aliaksen maininnan joka
kentän edessä.
--
Jusa Juutilainen - - - mustaan kulmaan katse jäi roikkumaan valkeutta
vasten kyynelten kaiku valittaen - - -
Jani Tiainen
>
> In article <3a768ecb$1...@news.vip.fi>,
> Markku Uttula <markku...@perlanet.fi> wrote:
>>Mahtaako seuraava esimerkki tyydyttää lainkaan aikaisempia enempää?
>
> Ehdottomasti paremman näköinen kuin aikaisempi. Muutamia (turhia)
> pointteja kuitenkin.
>
>>
>> select
>> avg(value)
>
> Mistä taulusta kenttä "value" haetaan? Olen itse todennut
> selventäväksi mainita aina mistä ollaan hakemassa. (Hypoteettisesti se
> voi olla myös SQL-parserille kevympää, tietääkö kukaan?)
Ainakaan käyttämäni Oraclen opukset ei tuosta mainitse
mitään. Todellisuudessa kenttä value voi olla missä tahansa taulussa
olettaen ettei saman nimistä kenttää ole muissa tauluissa. Sitä en muista
miten tuo käyttäytyy jos sattuu saman niminen kenttä kahteen eri
tauluun. Monitauluhakujen yhteydessä on kyllä järkevää viitata aina
siihen tauluun josta kenttä haetaan ettei tule epäselvyyksiä.
> Itsekin monasti käytän kirjainaliaksia, kuitenkin siten että
> kirjaimista näkee suoraan kuinka olen ajatellut liitoksen
> menevän. Tässä on ilmeisesti tehty samalla tavoin.
Paitsi että aliakset on ihan näppärä nimetä siten että niistä näkee mihin
tauluun se alias viittaa, helpottaa lukemista where-ehdossa.
>> where
>> value is not null and
>
> Avg-funktio jättää kyllä null arvot laskematta eli ei tätä tarvitse
> välttämättä mainita. Tietysti joskus voi olla suorituskyky etua
> mainita. Tästäkään ei käy esille missä taulussa value majailee.
Mitä suorituskykyyn tulee, ainakin useimmat opukset suosittelevat aina
järjestämään hakuehdot siten, että aina pienimmäksi rajaava ehto on
ensimmäisenä. Näin hakujen määrä verrattuna dataan jää pieneksi.
En tiedä onko tässä sitten tietokantamoottorikohtaisia eroja.
A Pietu Pohjalainen
> Ammatitaidon suhteen toki tuossa on pienoinen rike
> relaatiotietokanta-ajattelun suhteen (eli mikäli aloittelija-soluun ei
> kannata tallentaa osaamistasoa kuvaavaa tekstidataa vaan viittaus toiseen
> tauluun ID:llä, jossa tekstinpätkät on määritelty).
Soluja? Relaatiotietokannoissa?
Minä luulin aina, että siellä puhutaan tuppeleista ja monikoista
ja niin edes päin. Solut, rivit ja sarakkeet kuuluvat sitten käsitteinä
ehkä mielummin taulukkolaskennan puolelle.
t.Pietu
Jusa Juutilainen
>Jusa Juutilainen <pjuu...@spam-cs.joensuu.fi> wrote:
>>
>> In article <3a768ecb$1...@news.vip.fi>,
>> Markku Uttula <markku...@perlanet.fi> wrote:
>>> select
>>> avg(value)
>>
>> Mistä taulusta kenttä "value" haetaan? Olen itse todennut
>> selventäväksi mainita aina mistä ollaan hakemassa. (Hypoteettisesti se
>> voi olla myös SQL-parserille kevympää, tietääkö kukaan?)
>
>olettaen ettei saman nimistä kenttää ole muissa tauluissa. Sitä en muista
>miten tuo käyttäytyy jos sattuu saman niminen kenttä kahteen eri
>tauluun. Monitauluhakujen yhteydessä on kyllä järkevää viitata aina
Käyttäytyy siten että antaa virheilmoituksen, koska ei kyennyt
päättelemään mistä taulusta kenttä olisi pitänyt hakea.
>Paitsi että aliakset on ihan näppärä nimetä siten että niistä näkee mihin
>tauluun se alias viittaa, helpottaa lukemista where-ehdossa.
No itse näen sen varsin helposti myös kirjainaliaksista mutta en
vieroksu muitakaan tapoja.
>>> where
>>> value is not null and
>>
>> Avg-funktio jättää kyllä null arvot laskematta eli ei tätä tarvitse
>> välttämättä mainita. Tietysti joskus voi olla suorituskyky etua
>> mainita. Tästäkään ei käy esille missä taulussa value majailee.
>
>Mitä suorituskykyyn tulee, ainakin useimmat opukset suosittelevat aina
>järjestämään hakuehdot siten, että aina pienimmäksi rajaava ehto on
>ensimmäisenä. Näin hakujen määrä verrattuna dataan jää pieneksi.
>En tiedä onko tässä sitten tietokantamoottorikohtaisia eroja.
Pääperiaate on tietenkin juuri tuo ja kyllä, tietokantamoottoreilla on
varsin vekkuleita eroja.
Jos nyt otetaan esimerkiksi Oracle ja tuollainen "value is not null"
niin sen maininta voi olla fiksua jos kyseiselle kentälle on luotu
indeksi ja näin mahdollista tehdä kyseiseen indeksiin Fast Full Scan
(nullithan eivät mene Oraclessa indeksiin).
Toisaalta tälläiset irtoheitot ovat melkein aina huonoja koska usein
datan jakaumat ja muut tekijät aiheuttavat yllätyksiä.
Jyrki O Saarinen
: Mitä suorituskykyyn tulee, ainakin useimmat opukset suosittelevat aina
: järjestämään hakuehdot siten, että aina pienimmäksi rajaava ehto on
: ensimmäisenä. Näin hakujen määrä verrattuna dataan jää pieneksi.
: En tiedä onko tässä sitten tietokantamoottorikohtaisia eroja.
Voisi kuvitella että, tietokantasysteemit osaavat itse optimoida kyselyt
algebrallisesti? Tietäätkö kukaan?
Silvennoinen Sami
: Postscriptilla, johon tuossa viitattiin, ainakin on tehty kohtuullisen
: pervoja viritelmiä, ohessa esim. possu, joka renderöi pari hianoa palloa
: - kokoa huimat 706 byteä. Varoituksen sana: tuon tulostaminen kestää
: KAUAN :)
[tässä oli possua]
Wow! Nuo pallot oli aika hienot. Itse kirjoittelin aikoinaan piruuttani
Mandelbrotin joukon possuna (tulostaminen kestänee hetken):
---------8<---------------8<-------------------
%!ps
/iter 60 def /reso .005 def /sq { dup mul }
def /mod { 2 copy div floor mul sub } def
/plot { newpath moveto 1 0 rlineto stroke }
def gsave 280 420 translate 260 2 div dup
scale 2 260 div setlinewidth -2 reso 2 { /x
exch def -2 reso 2 { /y exch def /r 0 def
/i 0 def 0 iter { r sq i sq add 4 gt { exit
} if r sq i sq sub x add /i 2 r mul i mul y
add def /r exch def 1 add } repeat 10 mod
.1 mul .1 add setgray x y plot } for } for
grestore showpage
-----------8<----------------8<---------------
Iteraatioiden määrää voi säätää muuttamalla muuttujaa /iter, jonka arvo
on nyt 60. Resoluutiota taasen voi säätää muuttamalla /reson arvoa.
--
zam
Marko Manner-Raappana
Stephen Feuerstein, kirjoja esim. Oracle PL/SQL Programming) kehoittavat
välttämään optimoinnin jättämistä kannan huoleksi jos vain mahdollista, osa
tietokantamoottorin arvauksista ei ole lähelläkään optimiratkaisua.
/ /marko
Jyrki O Saarinen <jxsa...@cc.helsinki.fi> kirjoitti
viestissä:956hl2$na9$1...@oravannahka.helsinki.fi...
Tero Markus Ronkko
>> from
>> mu.person_knowledge a,
>> mu.user_info b,
>> mu.organisation c,
>> mu.knowledge d
>
> A, b, c, d? Onpa hyvin valitut aliakset... ;-P
Ohjelmointiin liittyen: Olen menestyksekkäästi ja mielikuvitusta osoittaen
nimennyt (delphi) ohjelmissani yksiköt Unit1 - Unitn.
Jotta varmistetaan yhdenmukaisuus, olen päättänyt nimetä lomakkeet Form1 -
Formn nimillä jne.
Kuinkahan yleistä tämän selkeästi kekseliään standardin käyttäminen on.
--
Rule of Defactualization: Information deteriorates upward through
bureaucracies.
Unknown
Aapo Rista
> Voisi kuvitella että, tietokantasysteemit osaavat itse optimoida kyselyt
> algebrallisesti? Tietäätkö kukaan?
Riippuu varmaan varsin paljon käytetystä tiedokantasysteemistä.
Ilmeisesti PostgreSQL:n 7.0.x-versio osaa optimoida kyselyt
varsin paljon 6.x.x-versioita paremmin - monimutkaiset, esim.
subselectejä ja liitoksia sisältävät kyselyt nopeutuivat
päivityksen jälkeen melkein kymmenkertaisesti.
(Mitään kovin tieteellistä tutkimusta en asiasta tehnyt, kokeilin ns.
näppituntumalla muutaman kannan kanssa.)
--
Aapo Rista
aapo.rista(at)iki.fi
Hanki eelämä - Get e life!
Aki Rossi
> nimennyt (delphi) ohjelmissani yksiköt Unit1 - Unitn.
> Jotta varmistetaan yhdenmukaisuus, olen päättänyt nimetä lomakkeet Form1 -
> Formn nimillä jne.
>
> Kuinkahan yleistä tämän selkeästi kekseliään standardin käyttäminen on.
Toivon mukaan ei kovin yleistä, ainakaan jos koodi on tarkoitettu muidenkin
luettavaksi/ylläpidettäväksi.
Jyrki O Saarinen
: välttämään optimoinnin jättämistä kannan huoleksi jos vain mahdollista, osa
: tietokantamoottorin arvauksista ei ole lähelläkään optimiratkaisua.
Hmm. Muistelisin, jotta kyselyillä on aivan selvä algebrallinen rakenne,
joten niiden on täysin mahdollista päästä optimiratkaisuun, jos se
kyselyn optimointi on yleensä toteutettu. Vrt.:
int x = a * b + a * c;
=>
int x = a * (b + c);
Jyrki O Saarinen
: välttämään optimoinnin jättämistä kannan huoleksi jos vain mahdollista, osa
: tietokantamoottorin arvauksista ei ole lähelläkään optimiratkaisua.
Hmm. Muistelisin, jotta kyselyillä on aivan selvä algebrallinen rakenne,
joten niiden on täysin mahdollista päästä optimiratkaisuun, jos se
kyselyn optimointi on yleensä toteutettu, eli mistään arvauksesta ei
toki ole kyse. Vrt.:
Vesa Lappalainen
Jos jotakin saisin Delphistä muuttaa, niin yksi ensisijalla oleva
olisi sellainen, että komponentin pudottamisen jälkeen sille
kysyttäisiin heti nimi ja ilman valituksia hyväksyttäisiin vain
numeroon päättymättömät ja vähintään 5 (tai sopiva luku) kirjainta
pitkät nimet. Kaikki Form1 jne. hylättäisiin automaattisesti.
Nythän oletuskäyttäytyminen oikein kannustaa huonoon ohjelmointiin!
Vesa
Markku Uttula
> Ehdottomasti paremman näköinen kuin aikaisempi. Muutamia (turhia)
> pointteja kuitenkin.
>
> >
> > select
> > avg(value)
>
> Mistä taulusta kenttä "value" haetaan?
Hyvä huomio. Koskapa kopioin koodinpätkän suoraan auki olleesta editorista,
ja kyseessä on pätkä kehitettävää ohjelmaa, tämä saattaa tulevaisuudessa
aiheuttaa hankaluuksia (mikäli muiden taulujen rakenteita muutetaan tai
otetaan hakuun mukaan toisia tauluja, joista saattaa myös löytyä
"value"-nimisiä kenttiä. Tämä korjattakoon... Kiitän kommentista.
> Avg-funktio jättää kyllä null arvot laskematta eli ei tätä tarvitse
> välttämättä mainita. Tietysti joskus voi olla suorituskyky etua
> mainita. Tästäkään ei käy esille missä taulussa value majailee.
Tämän uskoisin (en toki tiedä, koska en Oraclen moottoriin ole tarkemmin
tutustunut) johtuvan siitä, että mikälli avg-funktiolle viedään mahd. vähän
arvoja, suoritus olisi nopeampi. Saatan toki olla (taas kerran) väärässäkin.
> No sen enempää miettimättä näyttää ihan asiallisesta ja normaalilta
> liitosehdotelmalta. Näkisin tässäkin aliaksen maininnan joka
> kentän edessä.
Toisaalta myös aliaksen käytölle ei välttämättä tuossa olisi edes ollut
tarvetta. Tauluja, joista liitos tehdään, ei kuitenkaan ole tuon enempää,
joten ehkä olisi ollut parempi viitata niihin
taulun_nimi.kentän_nimi -tyyppisellä notaatiolla. Olisi saattanut olla
luettavampaa (sopivalla sisentelyllä jne. tietenkin varustettuna)?
--
Markku Uttula
Ilkka Virta
>olisi sellainen, että komponentin pudottamisen jälkeen sille
>kysyttäisiin heti nimi ja ilman valituksia hyväksyttäisiin vain
>numeroon päättymättömät ja vähintään 5 (tai sopiva luku) kirjainta
Ja samalla riistettäisiin ohjelmoijan vapaus tehdä komponentteja,
joiden nimeen loogisesti kuuluu se järjestysnumero?
Vesa Lappalainen
JA ILMAN VALITUKSIA, eli ei riistetä, vaan huomautetaan että aika
harvinaista. Koska käytännössä ne numeroidut komponentit
luodaankin ajonaikana taulukkoon. Mutta silti numeroita saisi -
totta kai - tehdä, mutta oletuksena niitä ei tehtäisi kuten nyt.
Ohjelmoija on laiska otus ja siksi nyt Delphi-ohjelmissa näkee
aivan liikaa numeroituja kun sitä ei ole pakko muuttaa.
Esim. itselläkin jää joskus apupaneelit numeroiduksi ja sitten
jälkeenpäin ihmetellään että mikähän tuonkin paneelin virka oli.
Labelitkin tuppaavat jäämään numeroiduiksi. Jos homma toimisi
toisinpäin, eli Labelin Caption muodostaisi komponentin nimen
sopivasti muutettuna, niin tätäkään ei tapahtuisi.
Itse asiassa kokeilin kerran property editoria jossa tein juuri
noin, eli kun Name-kohtaa klikkasi, niin se ehdotti
ComponentClass+Caption komponentin nimeksi. Siinäkin vaan
piti aina kilkata ja kun se name ei aina mahdu ruudulle, niin
jäi sitten klikkaamatta.
Vesa
Vesa
Juha Piispa
>Ilkka Virta <itv...@mbnet.fi> wrote:
>> On Wed, 31 Jan 2001 07:11:26 +0000 (UTC), Vesa Lappalainen wrote:
>
>>>olisi sellainen, että komponentin pudottamisen jälkeen sille
>>>kysyttäisiin heti nimi ja ilman valituksia hyväksyttäisiin vain
>>>numeroon päättymättömät ja vähintään 5 (tai sopiva luku) kirjainta
>
>> Ja samalla riistettäisiin ohjelmoijan vapaus tehdä komponentteja,
>> joiden nimeen loogisesti kuuluu se järjestysnumero?
>
>JA ILMAN VALITUKSIA, eli ei riistetä, vaan huomautetaan että aika
>harvinaista. Koska käytännössä ne numeroidut komponentit
>luodaankin ajonaikana taulukkoon. Mutta silti numeroita saisi -
>totta kai - tehdä, mutta oletuksena niitä ei tehtäisi kuten nyt.
>Ohjelmoija on laiska otus ja siksi nyt Delphi-ohjelmissa näkee
>aivan liikaa numeroituja kun sitä ei ole pakko muuttaa.
Tässähän olisi aivan erinomainen harjoitustyö!
Eli eikun opiskelemaan Open Tools APIa ja tekemääm tuo laajennus
Delphin IDEen.
Regards, Qapla'
Juha Piispa
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Juha Piispa | Tietovayla
Product Manager | PL 4
Enterprise tools | 00211 HELSINKI, FINLAND
Email JPi...@Tietovayla.fi,Tel. +358 9 6810 6108, Fax +358 9 678 780
WWW.Tietovayla.FI