[mirko28]

[Fukiku]

[2korda2]

[mirko28]

[inzinz]

Pakuks et morgothi mõte ei olnud mitte see, et üldse pole vaja PK vaid pigem see et alati ei pea olema autoincrement PK, kuna ta mainib kohe ka seoste tabelit.
Kui sul on MxN seoste kirjeldamise tabel, siis minimaalselt on sinna vaja ainult kahte välja: tabel1_id ja tabel2_id. Ja sinna ei ole eriti kasulik veel kolmandat välja juurde teha lihtsalt selleks et oleks autoincrement PK, vaid täiesti saab panna tabelile sellise PRIMARY KEY (tabel1_id, tabel2_id) mis tagab ka indeksite kombinatsiooni unikaalsuse.

estrose, kuigi esmapilgul võib tunduda nagu oleks firstpostid, lastpostid mõttetu andmete dubleerimine (kuna tõepoolest, saab post tabelist threadid järgi leida noorim ja vanim postitus) siis väheke edasi mõeldes selgub et asi ei ole siiski mõttetu dubleerimine vaid langeb umbes samasse kanti andmebaasi indekseerimisega kiiruse jaoks. Võta ükskõik millise foorumi esileht lahti ja mida sa näed: on foorumite nimekiri ja iga foorumi juures näha viimase postituse info. Võta alamfoorum lahti kus on threadide nimekiri näha: samamoodi on viimase postituse link ja info olemas. Nüüd kujuta ette et sul on andmebaasis 30 000 threadi, 2 miljonit postitust. Ja nüüd kujuta ette et selle threadide vaate välja kuvamiseks sa ei tee mitte lihtsalt "select * from thread where forumid=x" ja ei saa sealt koheselt kätte lastpostid vaid et iga thread row kohta peaks tegema subquery stiilis: "select id from post where threadid=x order by id desc limit 1".
Kui alamfoorumi vaates kuvatakse ette mingi 100 threadi rida, siis iga rea kohta jooksutatakse tema kohane subquery: 1 päringu asemel teed baasi rõõmsalt 101 päringut. Ja seda iga threadi vaate lehe kohta. Väga hea näide kus teoorias poleks vaja lastpostid, aga reaalselt kui asjalikumat jõudlust taga ajada on selline asi möödapääsmatu. Ja isegi kui sul on andmebaas indekseeritud hästi, siis iga subquery võtab ikkagi oma aja ära, mis sõltub väga suuresti post tabeli suurusest.


Le Inc, tõsiselt huvitab mis veebileht sul jookseb sellise indeksivaba andmebaasi peal nii rõõmsalt ? Ja kuidas siiamaani pole pähe torganud mõnda indeksit peale panna. Kui sa päringute järgi korraliku indeksi peale paned ei peaks kiirusevõit olema mingi hädine 3x vaid hoopis suurusjärgus 30x.
Esiteks see miks kustutamise peale asi aeglasemaks läks on see, et sul jäi asi optimeerimata peale kustutamist: olenevalt baasitüübist jäävad peale kustutamist tavaliselt tabelisse failisüsteemi tasemel nö augud sisse mis sunnivad baasimootorit kettalt teineteisest kaugemal olevaid andmeblokke lugema ning ka andmepuu läbimine võtab rohkem aega kuna puu ei ole optimeeritud.

Indekseerimise mõtet puust ja punaselt ette tehes: kui sul on indekseerimata andmebaasis 150 000 rida ja päring võtab aega 2 sekundit, siis 600 000 rea korral võid ilusti selle läbi korrutada neljaga ehk 8 sekundit päringu kohta kui otsid mingi välja alusel, kuna andmebaas käib järjest read läbi kuni leiab sobiva. Kui sul oleks aga otsitava välja peal indeks (ehk baas hoiab väärtuseid sorteeritult) siis sorteeritud välja korral saab leida sobiva rea ülesse kahendotsinguga: baas võtab keskelt väärtuse, võrdleb sinu otsinguga kas sai suurema või väiksema või õige väärtue, kui ei saanud õiget siis võtab 50% viimase sammu suurusest ülesse või allapoole ja kontrollib uuesti. 600 000 reaga tabelist õige rea ülesse leidmine võtaks maksimum 20 kontrolli selle asemel et kõik 600 000 ükshaaval läbi käia. 6 000 000 reaga tabeli korral 23 kontrolli (log2(ridade arv)), ehk 10 korda suurema baasi korral ei muutuks päring mitte 900% võrra aeglasemaks vaid kõigest 15% võrra. Ja sarnane jõudluse/kiiruse vahe on ka 600 000 reaga indekseerimata ja indekseeritud tabelil.

[Le Inc]

[mirko28]

[Renka]

[morgoth]

Pane siis foorumi tabelisse lastThreadId ning Teemade tabelisse lastPostId

[serk]

[mirko28]

[serk]

[mirko28]

[serk]

Andmemudeli mõistes oleks ju ilusam jah, kui sa hoiaks toote juures viimaseHInna ID'd aga performanci mõttes mitte. Aga noh, kui viitsimist, siis tee test. Loo PK hindade ajaloo tabelisse ning toote juures hoia siis viidet PK'le. Tee join ja vaata palju aeglasemaks jääb. Postita tulemused siia ja saamegi real-life näite, kas sinu puhul on see lahendus mõttekas või mitte

Foreign key abil saaksid ka hoida andmed jõuga süngis, ehk toote juures olev viimane hind on ALATI reaalselt eksisteeriv kirje ajaloo tabelis, mitte mingi lambi hind mis programmi veatõttu või tabelisse sattuda. Aga noh, oleneb süsteemist jällegi, kõik see teeb baasi aeglasemaks...

Ma olen muutunud laisaks, lasen baasil enamuse tööd ära teha, sealhulgas väga suure osa äriloogikast, eelistan seda hoida kas baasis või mõnes vahekihis aga kindlasti mitte UI's. Aga noh, tõenäoliselt ma kahetsen seda väljaütlemist, kuna see on umbes sama teema nagu kumb on parem, kas Windows või Linux

[mirko28]

Sellist ideed ka ennem soovitati:

[nemu]

Variant on ka partitsioneerida tabel lõpu kuupäeva järgi ja kasutada hetkel kehtiva jaoks "dummy" väärtust.
Kõik ilusti ühes tabelis ja hetke hindade jaoks käid ainult ühe partitsiooni kallal.
Näiteks:

[serk]

Mina kasutaks partitsioneerimist juhul, kui saaksin ühte partitsiooni panna min. 10 miljonit rida, isegi see on tegelt liiga vähe...

[2korda2]

serk,
andmebaasis äriloogikat üldiselt ei tehta. Põhjus elementaarne - mootori vahetumise korral tuleb suure tõenäosusega see kõik ümber kirjutada. Paras PITA. Samas ma eksin ka vahel selle vastu - andmebaasi elemendi uuendamine on võrreldamult lihtsam terve rakenduse vahetamisest, kui peaks LIVE keskkonnas äkki mingi kala välja ujuma.

Tabelite partitsioneerimine 650K kirje puhul ei ole üldiselt õigustatud. Kirjete arv peaks märksa suurem olema.

Le Inc ütles, et päringutes kasutatakse palju alampäringuid "in" konstruktsiooniga. Jällegi sõltuvalt mootorist on tulemused erinevad aga mina soovitan "exists" kasutada.

[nemu]

Ma ei suuda kuskilt välja lugeda, et see toote-hinna näide oleks sama mis LeInci 650k tabel.
Ridade arv ei ole samuti ainus aspekt, mida partisioneerimisel aluseks võtta.
Iga konkreetne juht tuleks eraldi läbi mõelda.

[serk]

[mirko28]

Oracle ja MS Sql-Server'i puhul on andmebaasi äriloogika programmeerimiseks kõik vajalikud vahendid olemas, ja on võimalik teha äriloogikat seal hõlpsalt, aga väiksemate andmebaasi mootorite puhul ilmselt on programmeerimis-Keskkond ilmselt kasin ja ei saagi eriti hõlpsalt keerumat äriloogikat realiseerida andmebaasi tasemel. Minu mäletamistmööda pole MySql-i andmebaasis kollektsioonide tuge üldsegi, kui googeldasin hiljuti selle kohta kuidas andmebaasi protseduurile kollektsiooni-parameetrit defineerida, siis sain vastuse, et polegi kollektsioone, et teha tuleks muud moodi, seega ilmselt pole eriti võimaluste-rohke MySql-i ja väiksemate andmebaasimootorite programmeerimise keskkond veel, ja ei ole hea neis äriloogikat programmeerima hakatagi seetõttu.

--

(tooksin siia ka definitsiooni PITA: Pain in the ass, pain in the arse)

[2korda2]

See, et vahendid on olemas, ei tähenda ju, et neid kasutama peaks :p
Kas olete võrrelnud, mis maksab ja kui keeruline on:
1. klasterdada rakendusserverit
2. klasterdada DB-serverit

Minul pole veel viimast tulnud teha, esimest aga on kasutatud päris mitmes projektis. Suurte lahenduste korral on tüüpiline lahendus, et rakendusservereid on terve pinu, need on suhteliselt lihtsad/odavad blade-tüüpi sahtlid. Nende taga aga töötab üks suur (ja kallis) DB server. Ka see on põhjuseks, miks peaks üritama andmebaasist äriloogikat välja saada - las DB server teeb ikka seda, milleks ta ette nähtud on - serveerib andmeid. Aga nagu öeldud - on teatud kontrollid, mida võiks DB tasemel teha. Äriloogikat DB-s teha on aga üldjuhul märksa kallim (pole OO-d).
Sel teemal leiab netist lugemist lademes:
http://www.codeproject.com/KB/architecture/DudeWheresMyBusinessLogic.aspx
http://giorgiosironi.blogspot.com/2010/02/where-is-business-logic.html
http://blogs.msdn.com/b/rogerwolterblog/archive/2006/04/04/568351.aspx

[serk]

Nagu ka ise ütlesid, it's all about money.

PL/SQL on programmeerimis keel
Java on programmeerimis keel
C on programmeerimis keel

Äriloogika võib panna mistahes keelde, mistahes kihti - pigem on asi ettevõte pikas perspektiivis ja platvormides mida soovitakse kasutada süsteemi alustalana. Eks see nii olegi, et kui äriloogika kasutajakihis, siis kogu pauk läheb rak. serverile ja vastupidi, rääkimata meetodidest kuidas üldse sellistel juhtudel rakendusi ehitada.

Ma ei tea, ma ei ülistaks OO niivõrd väga
Aga kui sellele juba jutt läks siis PL'ist:
Encapsulation - olemas, samuti inheritance ja polymorphism, nii et päris lootuseta see kraam pole OO suhtes

Tegelt vist peaks uue teema tegema, tegemist siiski MySQLi topicuga ja sujuvalt oleme teemat vahetanud

[mirko28]

[serk]

Päris nii see tegelikkuses pole - läbi Object Type'ide saab ikka päris palju tehtud ning pigem on tegemist teadmatusega Oracle erinevatest võimalustest.
OO Oracles on esmapilgul keeruline ja veel raskemini loetav, tema suurim miinus minuarust hetkel, aga eelneva jutuga suures osas küll nõustuda ei saa.

Kel huvi lugemiseks, andke tuld:
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14260/adobjint.htm#ADOBJ001

Üks vanem dok.