Gints Plivna

Nu te nu mēs redzam, kuriem interesē, lai viņu mājaslapās kāds nonāktu un kuriem patiesībā nevienu nevajag ;) Gints Plivna http://datubazes.wordpress.com

Drusku ne pa tēmu, bet reāli besī tie, kuri nevar mazliet mazliet izdarīt, lai strādātu arī īsās adreses. Piemēram - http://ikarte.lv/ nestrādā, obligāti vajag www, arghhhhhhh! Gints Plivna http://datubazes.wordpress.com

OOO vecie labie laiki :) SSā nav?

Nu tikai derētu atcerēties, ka eksistē arī tāda lieta, kā savienojumi, datu atlase nav tā kā iespējama tikai no vienas tabulas vien :) Gints Plivna http://datubazes.wordpress.com

SQLa nav, bet dati ir šeit. Gints Plivna http://datubazes.wordpress.com

AFAIK visas saprātīgas datubāzes spēj izmantot indeksus ar =, >, >=, <, <=, bet parasti nespēj ar <>. Protams, ir jautājums par to vai indeksa izmantošana vispār ir izdevīga, t.i., vai labāk nav izmantot pilnu tabulas pārlasi. Katrā DBVS ir lieta, kas saucās apmēram vaicājumu optimizators, kas redzot SQL teikumu, ievērtējot datu sadalījumu un vides konfigurāciju nolemj, kas katrā gadījumā ir izdevīgāks, vai ir vērts indeksu lietot vai nē. Protams, ka: 1) optimizators skatās uz tādām vai citādām tabulu statistikām, kas ne vienmēr ir up to date, tāpēc lēmums var būt nekorekts dēļ tā 2) optimizators ir cilvēka rakstīts algoritms, kas nav perfekts un var pieņemt ne to pašu labāko lēmumu 3) cilvēkiem parasti ir tendence domāt, ka lietot indexus ir labi un izmantot pilnu tabulas pārlasi slikti, bet ne vienmēr tā ir, pareizāk sakot, itin bieži ir tā, ka indekss->tabula tikai traucē. Tas ir atkarīgs no vairākiem faktoriem, atlasāmo ierakstu skaita vs kopējais ierakstu skaits tabulā, ierakstu fiziskais novietojums datu blokos (vai visi ieraksti ar vienu un to pašu meklējamo kolonas vērtību ir novietoti kompakti kopā, vai arī izmētāti pa visiem datu blokiem tabulā) utml. Gints Plivna http://datubazes.wordpress.com

DBVS??????? Interesanti, cilvēki saprot, ka, prasot koda gabalu, piemēram, burbuļa kārtošanas metodei, ir jāpasaka, vai to vajag C, PHP vai Javā. Bet tai pašā laikā saprast to, ka katrā DBVS ir pietiekami lielas atšķirības starp SQL dialektiem, nekādi nespēj. Vai arī tie, kas darbojas ar PHP, principā neko citu kā MySQL nekad neizmanto? ;) Nespēju reāli šo lietu vienkārši nekādi saprast :O OK beidzu moralizēšanu un saku, ka MySQLam vispārīgam gadījumam rekursīvu vaicājumu nav. Noteiktam skaitam var izmantot pašsavienojumus tik reizes cik vajag. Skat sīkāk rekursīvie vaicājumi, kur ir arī saite uz rekursīva modeļa pieraksta veidu, kur visu bērnu atlasīšanu var dabūt arī MySQLā. Gints Plivna http://datubazes.wordpress.com

Mmm no komandrindas to var darīt šādi: mysql.exe -umyuser -pmypass mydb < file.name kur myuser - lietotājs mypass - parole mydb - datubāze file.name - skripta fails http://dev.mysql.com/doc/refman/5.0/en/batch-commands.html Jādomā, ka no php var izsaukt OSa komandu :) Esmu gatavs ticēt, ka eksistē tādi gadījumi, kad tā nezin kādu iemelsu dēļ nevar darīt, bet nu vismaz šo lietu ir vērts apsvērt. Gints Plivna http://datubazes.wordpress.com

Kas tieši nestrādā? Kā tas izpaužās? Atkal jāuzdod kāds bariņš ar precizējošiem jautājumiem, lai kaut ko saprastu? ;) Gints Plivna http://datubazes.wordpress.com P.S. OK anyway, cik saprotu, tad esi atradis savu risinājumu un, ja tas strādā, tad, protams, nav vērts rakt paralēlā virzienā.

Šis jautājums kā labs piemērs manī līdz galam izprovocēja sen gruzdošo vēlmi uzrakstīt piemēru precīzam jautājumam. Gints Plivna http://datubazes.wordpress.com/

http://lmgtfy.com/?q=mysql+paging Izrādās, ka arī es jau kādreiz kaut ko tādu rakstīju :) http://datubazes.wordpress.com/2009/10/13/pirmo-n-ierakstu-atlase/'>http://datubazes.wordpress.com/2009/10/13/pirmo-n-ierakstu-atlase/ Gints Plivna http://datubazes.wordpress.com

Nu par 90% ir: mysql> SELECT node.name, node.category_id -> FROM nested_category AS node, -> nested_category AS parent -> WHERE node.lft BETWEEN parent.lft AND parent.rgt -> group by node.name -> order by group_concat(parent.name ORDER BY parent.lft); +----------------------+-------------+ | name | category_id | +----------------------+-------------+ | ELECTRONICS | 1 | | PORTABLE ELECTRONICS | 6 | | 2 WAY RADIOS | 10 | | CD PLAYERS | 9 | | MP3 PLAYERS | 7 | | FLASH | 8 | | TELEVISIONS | 2 | | LCD | 4 | | PLASMA | 5 | | TUBE | 3 | +----------------------+-------------+ 10 rows in set (0.00 sec) Uzlabots variants Gints Plivna http://datubazes.wordpress.com

Kas ir seciba? Kaut kāds kārtas numurs augšējā līmeņa ietvaros? Tajā modelī nekā tāda nav. Klau Tu varētu: 1kārt, ja Tavu tabulu struktūra atšķiras no tā, kas dots oriģinālajā rakstā, tad iedot create table teikumus + insertus tiem dažiem datiem 2kārt precīzi formulēt to, kas sanāk un to ko vajag. Piemēram, lūk šādi: Šobrīd varu dabūt šādi: mysql> SELECT node.category_id id, -> CONCAT( REPEAT(' ', COUNT(parent.name) - 1), node.name) AS name -> FROM nested_category AS node, -> nested_category AS parent -> WHERE node.lft BETWEEN parent.lft AND parent.rgt -> GROUP BY node.name -> ORDER BY node.lft; +----+-----------------------+ | id | name | +----+-----------------------+ | 1 | ELECTRONICS | | 2 | TELEVISIONS | | 3 | TUBE | | 4 | LCD | | 5 | PLASMA | | 6 | PORTABLE ELECTRONICS | | 7 | MP3 PLAYERS | | 8 | FLASH | | 9 | CD PLAYERS | | 10 | 2 WAY RADIOS | +----+-----------------------+ 10 rows in set (0.00 sec) Vajag lai būtu: +----+-----------------------+ | id | name | +----+-----------------------+ | 1 | ELECTRONICS | | 6 | PORTABLE ELECTRONICS | | 10 | 2 WAY RADIOS | | 9 | CD PLAYERS | | 7 | MP3 PLAYERS | | 8 | FLASH | | 2 | TELEVISIONS | | 4 | LCD | | 5 | PLASMA | | 3 | TUBE | +----+-----------------------+ Kur visas apakškategorijas ir sakārtotas alfabētiski virskategorijas ietvaros. P.S. Nav ne jausmas kā var dabūt 2ro variantu, bet gan jau ka var :) Gints Plivna http://datubazes.wordpress.com

Tā arī neiebraucu - a kur tieši ir problēma? Kas ir tas ko vajag panākt, bet nevar? Tb kā tam jāizskatās, ko vajag panākt? Gints Plivna http://datubazes.wordpress.com

Nē nu gribēt nevienam nav aizliegts, es, piemēram, gribu Ferrari, tikai neviens nedod :) Ja par programmētāju neiesi strādāt un mācīties arī negribas, tad iespējams vajag sameklēt kādu, kas Tev to izdara, nu tikai sagatavo kādu $$ pirms tam ;) Gints Plivna http://datubazes.wordpress.com

Paga, paga, to visu var izdarīt tikai nevajag lietot DISTINCT, bet kā jau iepriekšējais kolēģis teica, group by. Vienkārši sākotnēji nebija pilnīgi nekādas infas ko tai id vietā vajag, ja der jebkurš, tad SELECT `id`, `title`, `surname`, `name` FROM `table` WHERE `other` = '1' GROUP BY `name` Tagad būs unikālie `name`, bet pārējie lauki kādi pagadīsies, priekš konkrētā 'name'. Gints Plivna http://datubazes.wordpress.com

Tagad uzzīmē uz papīra sev šo situāciju un padomā, ko Tu gribēsi diviem ierakstiem redzēt tad, ja Name tiem sakrīt, bet id kā pats saki atšķiras. Kā izskatīsies id? Tur arī tas garām ir paslēpts, bet garām priekš konstrukcijas DISTINCT, iespējams ar kaut ko citu var līdzēt, bet vispirms ir jābūt skaidrai vīzijai, ko vajag panākt :) Gints Plivna http://datubazes.wordpress.com

Ak dies :S Jautājums - Tu saproti, ko nozīmē savienojumi (join)? Ja ne, tad palasi kaut vai šeit. Tālāk balstoties uz to info paskaties uz šo piemēru un mēģini saprast no kādām trīs daļām tiek veikts šis savienojums. Tālāk es Tev iepriekšējā postā saku, ka šim pēdējam uzdevumam Tev ir jāizmanto tā pati tehnika vai ideja, kas izmantota šai piemērā, tikai jāņem otrā un trešā savienojuma daļa. Tālāk es saku, ka vajag uztaisīt savienojumu ar sevis paša tabulu, tas nenozīmē, ka jātaisa jauna tabula, tas nozīmē, ka jātaisa pašsavienojums (self join), kur tā pati tabula, jeb izteiksme no tās ir vienkārši jāizmanto 2 reizes. Es, protams, varētu šo SQL teikumu uzrakstīt bez problēmām, bet labāk pamēģini pats to izdarīt. Gints Plivna http://datubazes.wordpress.com

Ja vajag tikai skaitu, tad tas pirmais variants ir kaut kādas šausmas un ārprāts. Iedomājies Tev ir 3 grāmatplaukti, kurā ir akurāti saliktas grāmatiņas, kurām visām var redzēt muguriņas. Tā vietā, lai kaut vai pirkstu piedurot pie katras tās saskaitītu, grāmatas tiek ņemtas ārā no visiem 3 plauktiem un akurāti kraujot zemē saskaitītas :) Cik nu var spriest pēc sākotnējā koda fragmenta, tad xPtv45z dotais variants ir īstais. Gints Plivna http://datubazes.wordpress.com

Nu tas Tev mājasdarbs :) Varu pateikt hintu, ka jāņem mana pēdējā atbilde un no tās 3 savienotajām tabulām/apakšpieprasījumiem vajag pēdējos 2. Attiecīgi šādus uzdevumus risinot vajag tos sadalīt sīkāk, 1. solī atlasi grupas id un maksimālo laiku, otrā solī tiem uztaisi savienojumu ar sevis paša tabulu, kur atlasi pēc attiecīgā id un laika pārējās detaļas. Gints Plivna http://datubazes.wordpress.com

Konstrukcija ir garām. Labāk pastāsti, ko Tev vajag. Gints Plivna http://datubazes.wordpress.com

Jādara 2 soļos t.i. jātaisa vēl viens savienojums. Vispirms noskaidrojam katrai grupai lielāko topika id, tad katram id pielasam datus. SELECT g.id AS group_id, g.name, g.picture, t_id, t.title, t.time AS topic_time FROM groups g LEFT JOIN ( SELECT group_id, max(id) t_id FROM topics GROUP BY group_id) AS max_rows ON (g.id = max_rows.group_id) LEFT JOIN topics t ON (max_rows.t_id = t.id) Gints Plivna http://datubazes.wordpress.com

A kas ir iistie? ;) MySQLa praat iistais ir pirmais, kursh pagadaas. Un to jau Tu peec buutiibas esi prasiijis, Tu gribi maksimaalo id, bet neko nesaki par to kaadu title gribi. Un vispaar shai zinjaa MySQLs ir ljoti pielaidiigs, citaas DBVS shitaada haltuura (tas ka var grupeet peec mazaaka kolonu skaita nekaa select lista vienkaarshie elementi) neietu cauri. Gints Plivna http://datubazes.wordpress.com/

Designing DDL Triggers DDL Triggers Gints Plivna http://datubazes.wordpress.com

KUR? Veelreiz (sorry nav latv burtu uz klavas) atgaadinu, ka DBVS ir svariiga :) Oracle, SQL Server - Jaa MySQL - AFAIK nee Gints Plivna http://datubazes.wordpress.com/