Keskustelu: Nettisivujen teko: SQL lisäys

Onko SQL kilellä esim. MySQL:ssä mahdollista tehdä sellainen lause, joka UPDATE käskyllä lisää kentän loppuun tai alkuun jotain niin että vanha sisältö säilyy?

Siis jotekin näin UPDATE table1 SET filed1 = field1+" jotain" WHERE table1.id = 1 LIMIT 1;

Kokeile näitä:

SET teksti = CONCAT('aaa', teksti)
SET teksti = CONCAT(teksti, 'bbb')
SET teksti = CONCAT('aaa', teksti, 'bbb')

Merkkejä voi siis lisätä merkkijonon alkuun tai loppuun tai molempiin.

entäs sitten tuo sama relatioilla?

esim. päivitä kaikki kentät jotka on X päivää vanhoja ja laita talun1 relation siis taluun2 kaikkin kohtiin joissa on talun1 rivin ID sama ja jos ei ole riviä ks. ID:lle niin lisää se.

Voiko UPDATEssa käytää JOINeja?

Onnistuiskohan tuo jotenkin tyyliin UPDATE table1 SET field1 = (SELECT data FROM table2 WHERE id=3)+"jotain" WHERE table1.id = 1 LIMIT 1 ?

Kyselyn sisäiset kyselyt on toisaalta pirun hitaita. Yks vaihtoehto tietty hoitaa php:n tms puolella tuo yhdistys.

Dramo kirjoitti:

Kyselyn sisäiset kyselyt on toisaalta pirun hitaita. Yks vaihtoehto tietty hoitaa php:n tms puolella tuo yhdistys.

Eivät kai ne niin hitaita ole... Käsityksessä ollut että ne olisivat ihan yhtä nopeita kuin normaalitkin kyselyt, eli pirun nopeita kunhan käytetään indeksejä.

Indexit nopeuttaa jo mutta jos niitä käytetään turhaan niin ne kuluttaa vaan turhaan levytilaa.

Luin tosta SQL-opaasta että Oreclessa on MERGE käsky joka updatettaa jos tieto on jo olemassa ja INSERTaa jos tietoa ei ole. MySQLässä sama tapahtuu REPLACE käskyllä

walkout_ kirjoitti:

Indexit nopeuttaa jo mutta jos niitä käytetään turhaan niin ne kuluttaa vaan turhaan levytilaa.

Totta ja lisäksi hidastaa lisäyksiä. Jos jotain aikasarja-tyyppistä dataa tallentaa tiheästi, niin kannattaa mielummin jättää indeksoimatta. Webbisoftissa tulee nyt ensimmäisenä mieleen jonkinlainen kävijälaskuri, jonne siis tehdään paljon enemmän INSERTejä kuin SELECTejä.

Indeksit, niin monta oikeaa ja niin monta väärää käsitystä, mutta tässä kuitenkin tietokantamaailmasta pari oikeaa:

1) indeksejä kannattaa käyttää kun sarakkeeseen tehdään paljon select käskyjä tai liitos/liitoksia
2) ei kannata indeksoida jos eri arvoja on vain muutama (1-5 suurinpiirtein)

Alikyselyistä: kannattaa käyttää korreloituja alikyselyitä ja jos mahdollista, EXISTS käskyä (joka on tooodella nopea verrattuna muihin).

MySQL:ssä perinteinen tapa nopeisiin kyselyihin ja isojen indeksien käyttöön: muutokset InnoDB tauluun jossa ei ole indeksejä josta replikoidaan data myisam tauluun jossa indeksejä.

Ja sitten se, että tietokannoissa miljoona riviä on vähän, 10 miljoonaa riviä on jo hieman, 100 miljoonaa riviä on jo jonkin verran ja siitä ylöspäin paljon.

Kuten eräs virkatoveri sanoi IBM:llä: "melkein jokainen osaa tehdä tietokannan joka toimii, mutta kaikki eivät osaa tehdä tietokantaa joka toimii oikein". Kuten lauseesta voi päätellä, joskus se ero voi olla hiuksenhieno.

--W--

Wizard kirjoitti:

MySQL:ssä perinteinen tapa nopeisiin kyselyihin ja isojen indeksien käyttöön: muutokset InnoDB tauluun jossa ei ole indeksejä josta replikoidaan data myisam tauluun jossa indeksejä.

Ihan uteliaisuudesta: miten nämä sitten pietään synkassa?

Blaze kirjoitti:

Wizard kirjoitti:

MySQL:ssä perinteinen tapa nopeisiin kyselyihin ja isojen indeksien käyttöön: muutokset InnoDB tauluun jossa ei ole indeksejä josta replikoidaan data myisam tauluun jossa indeksejä.

Ihan uteliaisuudesta: miten nämä sitten pietään synkassa?

Replikointi tai triggerit esimerkiksi.

-W-

Wizard kirjoitti:

MySQL:ssä perinteinen tapa nopeisiin kyselyihin ja isojen indeksien käyttöön: muutokset InnoDB tauluun jossa ei ole indeksejä josta replikoidaan data myisam tauluun jossa indeksejä.

Mikä hyöty tällä siis saavutetaan? Nopea lisäys ja haku, vai hallinnoiko myisam indexejä jotenkin optimaalisemmin?

Wizard kirjoitti:

Replikointi tai triggerit esimerkiksi.

Mikäli ymmärsin oikein, niin tarkoitit triggerillä siis triggeriä innoDB-tauluun. Eikö clientin kyselyyn käyttämä aika kuitenkin sisällä tuon triggerinkin suorituksen?

ajv kirjoitti:

Wizard kirjoitti:

MySQL:ssä perinteinen tapa nopeisiin kyselyihin ja isojen indeksien käyttöön: muutokset InnoDB tauluun jossa ei ole indeksejä josta replikoidaan data myisam tauluun jossa indeksejä.

Mikä hyöty tällä siis saavutetaan? Nopea lisäys ja haku, vai hallinnoiko myisam indexejä jotenkin optimaalisemmin?

Wizard kirjoitti:

Replikointi tai triggerit esimerkiksi.

Mikäli ymmärsin oikein, niin tarkoitit triggerillä siis triggeriä innoDB-tauluun. Eikö clientin kyselyyn käyttämä aika kuitenkin sisällä tuon triggerinkin suorituksen?

Nopea lisäys innodb tauluun jossa ei indeksejä. Muutoksien hitaus isoissa tauluissa johtuu siitä, että jokaisen muutoksen jälkeen indeksi(t) joudutaan rakentelemaan uudelleen. Innodb:ssä on parempi tuki muutenkin noille lisäyksille sekä niiden hallinnoimiseen (sekä tarkkailuun).

Ja tuossa tuli ajatusvirhe - triggereitä EI voi käyttää.

Myisam taulu taas on nopeampi puhtaissa select kyselyissä ja siellä käytetään sitten normaalisti indeksejä hakujen nopeuttamiseen.

Suosittu tapa siellä missä tarvitaan paljon potkua MySQL palvelimista. Kysehän on jo moottorien erilaisuudesta: myisam tarjoaa nopeutta (mutta ei luotettavuutta) ja innodb tarjoaa luotettavuutta suorituskyvyn kustannuksella.

Googlekin kertoo asiasta jonkin, vaikka nyt aluksi hakusanoilla: mysql + replication + innodb + myisam

-W-

Ok, ihan hyvä tietää, vaikka omat sovellukset nyt harvoin yltävät edes 10k riviin ja haku- ja lisäysajat pysyvät kurissa ilman sen kummempaa optimointia :)