pie 'ALGORITHM = MERGE' cache gan tiek izmantots normālā veidā, optimizēšana gan vairāk attiecas uz sql rakstītāja sirdsapziņas un indexu pieejamības. Bet optimizējot attiecīgos selectus, iegūt nepieciešamo funkcionalitāti, lietojot view'us, ir iespējams (nerunājot par tiešām specifiskām lietām).

lietotājs: Neder. Man ir tabula, kura tiek apdeitota (INSERT/UPDATE) reizi dažās sekundēs. Ierakstu skaits sliecās pāri vairākiem miljoniem. Attiecīgi, ar nožēlu jāatzīst, ka cache nepalīdz, jo tabula mainās pārāk bieži. Selektā tiek grupēts pēc INT(11) lauka, uz kuru ir indekss. Selekts vidēji izpildās vairākas minūtes. Man vairāk patiktu, ja es uztaisītu VIEWu un tas, teiksim, reizi desmit/piecpadsmit minūtēs <em>fonā</em> pats sevi lēnām reģenerētu.

Selekta optimizācija nav iespējama, jo tas ir pats vienkāršākais grupēšanas selekts. Indeksu optimizācija, cik nu es saprotu, arī nav iespējama. Jo lauks, pēc kura tiek grupēts, ir viens.

Pilnīgi iespējams, ka šai problēmai ir cits risinājums, bet man kā RDBMS nespeciālistam nekas prātā nenāk (ja neskaita jaudas audzēšanu un db klāsterēšanu).

nejauc "view" ar "materialized view".

pat postgre nav kaartiiga atbalsta materializeetajiem skatiijumiem. ja ar to grib nodarboties nopietni, tad jaanjem oracle vai kas tamlidzigs.

Khm, Laacz, bet kur tad notiek tā, kā Tu gribētu? Cik skatos, microsoft sql arī parastie view-i ir tieši tādi, kā Tu apraksti, proti, ģenerēti atvēršanas laikā. Cita lieta, indeksētie skati, kas patiesībā tādas pat tabulas vien ir.

misame: Tie tomēr ir nevis parastie viewi, bet gan materializētie, kurus MySQL nesuportē. Tie mani arī interesē. Piem., <a href="http://www.ss64.com/ora/mview_c.html" title="Create Mview" rel="nofollow">tā tas ir iekš ORA</a>.

pastaas te: http://forums.mysql.com/read.php?100,21746,33143

Un kādas problēmas realizēt materiālo skatu, izmantojot trigerus? Vismaz postgresql tas vienmēr izdevies eleganti.

valdiic - kaadas probleemas paarvietosanos no maajaam uz darbu 20km realizeet, izmantojot kaajas?

sql: un jūs, cienītais, piedāvājat braukt ar ļoti, ļoti dārgu taksi? Es laprātāk izmantoju sabiedrisko transportu, kas šajā gadījumā, manuprāt, atbilst trigeriem. Nav tik ērti, bet rezultāts ir labs.

ir tak Oracle Database 10g Express Edition

http://www.oracle.com/technology/products/database/xe/index.html

Tādā gadījumā, kad ir vajdzība lietot materiālos skatus, Oracle Database 10g Express Edition diez vai derēs. Oracle Database XE ir ierobežojoši faktori: 4GB lietotāja dati (uz hdd), 1GB RAM, 1CPU. Tik mazās datubāzēs materiālie skati parasti nav nepieciešami.

valdiic: kā redzi, jau pie dažiem miljoniem rindu sāk gribēties materializētos skatus. Un tas noteikti neaizņem 4gb.

misame, un cik pēc tavām domām aizņem sakarīga tabula ar vairākiem miljoniem ierakstu + vēl materiālie skati? Man šķiet, ka ar 4 GB ļoti drīz būs par īsu. Jadomā taču uz priekšu. Tādos retos gadījumos, kad ir skaidri zināms, ka datubāzes lietotāja datu kopējais izmērs nekad, nekad neaizņems vairāk par 4GB, Oracle piedāvāto XE var lietot. Bet es tomēr iesaku palūrēt mazliet tālāk par savu degungalu. ;)

tu esi paarliecinaats ka tava selektaa tiek izmantots indeks? paaris minuutes, tas jau izskataas uz full table scan!

1. pameegjini to pashu selektu, tikai bez group by (lai redzeetu vai bremzee deelj grupeeshanas vai nee)
2. indexam, protams, ka jaabuut arii uz where nosaciijumiem.

2 valdiic - ir redzeetas arii datubaazes ar 10 mlj ieraxtiem, kas aiznjemt

2 valdiic - ir redzeetas arii datubaazes ar 10 mlj ieraxtiem, kas aiznjemt

2 valdiic - ir redzeetas arii datubaazes ar 10 mlj ieraxtiem, kas aiznjemt zem 1GB. visa db tiek ielaadeeta un glabaata atminjaa. ilgaakais selects izpildiijaas 10 sec, un tas jau bija pasaules gals (oracle optimizeris izdomaaja ignoreet inexus). ar indexiem selekts izpildaas momentaali (zem 1 sec). nu db serveris protams, atbilstosh, ar 4etriem xenon cpu.

bljin, ziimi mazaaks nevar ieraxtiit.