Gints Plivna

Tu tiešām gribi jebkurus 10 ierakstus, kuri pagadās? Ja gribi tomēr pēc noteikta sakārtojuma, tad http://datubazes.wordpress.com/2009/10/13/pirmo-n-ierakstu-atlase/ Gints Plivna http://datubazes.wordpress.com

Te kaut kas nelīmejas kopā. Ja vajag meklēt/apstrādāt tikai jaunākos/aktuālos ierakstus, tad kāda mārrutka pēc tur būtu jālieto UNIONS, ja speciāli jaunākie dati ir tikai VIENĀ NO TABULĀM, un kā es saprotu no postētāja, ne jau meklēšanā ir problēma. Problēma ir kaut kādā mistiskā apstrādē "izvilkt visus datus un apstrādāt oderdojot pēc id desc. izmantoju šādu kveri:" Un es personīgi nesaprotu pat pie šo 2 tabulu situācijas, kāpēc šāda apstrāde ir problemātiska un kā 1 tabula šai gadījumā būtiski palīdzēs? Jo pat, ja šos datus iebāzīs 1 tabulā, kopējais nolasāmais ierakstu daudzums diez vai samazināsies, ja apstrādes loģika nekā netiks mainīta, vienīgais ko mēs iegūsim, tas ir, ka MySQL nebūs jāapvieno abu tabulu dati un tie pēc tam jākārto, bet to varēs darīt uzreiz kaut vai pēc PK indeksa. Ja vien dzelzis nav kaut kāds pilnīgi no akmens laikmeta, vai iespējams MySQLs sakonfigurēts tā lai tam atmiņa būtu daži K (nezinu vai tā var izdarīt), tad ieguvums būs tuvu 0. Manuprāt, lielākā bremze jebkurā gadījumā būs šos 35K ierakstus nolasīt un "apstrādāt", lai ko tas arī nenozīmē, nevis apvienot un sakārtot no 2 tabulām. Gints Plivna http://datubazes.wordpress.com P.S. Tas ko ar visu šo penteri gribēju pateikt - ka 2 tabulas ir diezgan sviestaini, bet apvienojot datus vienā un nemainot šo "apstrādes" loģiku (atlasīt visus datus), diez vai būs kāds vērā ņemams ieguvums.

Ko nozīmē apstrāde? Ja visu ierakstu (kopā saprotu, ka 35K, kas patiesību sakot ir pupu mizas) apstrāde notiek reti,tad kuru uztrauc tās 2 sekundes, piem, pāris reizes diennaktī? Savukārt, ja VISUS ierakstus ir jāapstrādā bieži, tad kas ir tas par tādu dīvainu procesu un biznesa nepieciešamību, ka ik pēc maza laika jāizgriež cauri visus datus? Te vispirmām kārtām vajadzētu saprast kā un kāpēc ir organizēts process un ko vajag panākt un tikai tad ķerties pie darbiem. Gints Plivna http://datubazes.wordpress.com

Jā un gribēju piebilst, ka viedoklis "pirmām kārtām viss ir atkarīgs tikai no paša vēlmes mācīties un strādāt", nav tikai mans personīgais, bet tā vai līdzīgi domā bariņš cilvēku, kas ir atbildīgi par darba spēka pieņemšanu un atlaišanu vairākās iestādēs, ar kurām oficiāli vai neoficiāli ir bijusi darīšana un/vai pazīšanās :) Tieši tas pats viedoklis ir attiecība arī pret sakrālo jautājumu - kur labāk studēt - LU vai tehniskajā? Gints Plivna http://datubazes.wordpress.com

Nuuuu 1. ģimnāzija, protams, skan lepni un vispār šis skolas absolventiem ir tāda kopīga iezīme, ka veselīga nekaunība, bet tas, ka tikai tur varēs iemācīties mācīties galīgi nav tiesa. Es zinu, gan ļoti veiksmīgus šīs skolas absolventus, gan tādus, kas ne ar ko neizceļas uz vidējā fona, gan tādu, kas kā daudzsološs spīdeklis tur aizgāja mācīties, gadu noluņoja (jo vairs nebija vecāku stingrās acs), atnāca atpakaļ uz savu mazpilsētas skolu un to pat tā arī nepabeidza, jo 1. ģimnāzijā bija iemācījies nevis mācīties, bet luņot. Tā kā pirmām kārtām viss ir atkarīgs tikai no paša vēlmes mācīties un strādāt. Nu ok un no tā, lai nemācītos kaut kādā galīgā žopā, kur skolotājiem viss ir pilnīgi vienalga, kas notiek ar audzināmajiem. Gints Plivna http://datubazes.wordpress.com

Par vidusskolu un tehnikumu runājot - kā jau tas principā ir domāts, tad vidusskola dod plašāku vispārēju izglītību salīdzinot ar tehnikumu, kurš parasti ir tendēts vairāk vienā konkrētā virzienā. Es mācījos videnē, jo: 1) pēc pamatskola man galīgi nebija ne jausmas ko es vēlos vēlāk darīt, t.i., man bija vienlīdz labas sekmes (tb 5 pēc tā laika skalas) daudzos priekšmetos un interese par tiem - gan matemātikā, gan ķimijā, gan latviešu valodā un literatūrā, gan ģeogrāfijā un vēl šur tur 2) nejutos vēl pietiekami patstāvīgs (iespējams drīzāk vecāki nejutās), lai vāktos uz citu pilsētu. Par to, ka startēšu uz IT, es izdomāju tikai videnes pēdējā klasē apsverot manas intereses vs potenciālās darba iespējas, pie tam bija vēl pāris rezerves varianti, kur iesniedzu dokus, ja nu kas nesanāk un netieku budžetā. Tas, ka kāds bars universitātē sākotnēji prata programmēt labāk nekā es, galīgi nenozīmē to, ka viņu sākotnējais handikaps tāds saglabājās arī tālāk :) Tā kā mans uzskats ir tāds - ja cilvēks zin, ko viņš vēlas, jau beidzot pamatskolu un ir pietiekoši patstāvīgs, tad var durt uz tehnikumu un urbt izvēlēto jomu. Bet, ja īstas skaidrības nav, tad videne dos plašāku ieskatu dzīvē un 3 gadi ir laiks + pieredze, lai pieņemtu izsvērtāku lēmumu. Savukārt, ja izrādās, ka tehnikumā nav tas ko tu vēlējies, tad būs grūtāk pārorientēties. Bet tas atkal ir ļoti nosacīti, jo es zinu cilvēku, kurš pabeidza kokapstrādes tehnikumu, pēc tam saprata, ka tas nav tas ko vēlas, iestājās augstskolā datorzinātnēs un tagad labi un veiksmīgi strādā IT. Kas attiecas uz visādiem tur Stīviem un Biliem, kas aizvācās no universitātēm tās nepabeidzot, tad tie ir izņēmumi, kas apstiprina tikai to, ka, ja esi pietiekami talantīgs, tad pašmācības ceļā un neluņojot darba gaitā iegūsi tikpat un vairāk kā tie, kas ir mazāk talantīgi un/vai slinki un mācās atbilstoši standartam. Nav viena vienīga ceļa, tas nu ir skaidrs. Yeahhhh gandrīz kā stāsts par Dao sanāca ;) Gints Plivna http://datubazes.wordpress.com

Nu šis risinājums sako vienkārši nemērā, nav vērts kāpt uz grābekļa, ar kuru jau ntie cilvēki ir norāvušies pa pieri. Vajadzētu pieturēties pie koncepta, ka ID - tas ir unikāls (un TIKAI) identifikators, tas nav nekāds numurs pēc kārtas. Numurus pēc kārtas iegūst atlasot datus. Ja nu ļoti vajag tos nemainīgus (tipa pavadzīmēm utml), kur reāli to prasa likumdošana, tad tam ir atsevišķs lauks un nevis ID. Citādi pats sev radīs daudzas problēmas: - ja vairāki lietotāji veic darbības vienlaicīgi, dabūs to pašu nākošo id - ātrdarbības problēmas, jo tāda nākošā id atlase ir krietni lēnāka nekā autoincerment - ko darīt, ja kāds ieraksts jādzēš, vai tagad pārnumurēt visus nākošos idus un arī visus saistītos ierakstus (FK) - utt, utjp Gints Plivna http://datubazes.wordpress.com/

Nu atkarībā no tā, ko saprot ar "var taisīt", ir piemēram arī šādas iespējas: http://lv.wordpress.com/features/ Bet nu, lai arī tam nevajag praktiski nekādu programmēšanas zināšanu, tomēr tur būs nepieciešamas zināmas iemaņas gramatikā, ja vien komunikācija nav plānota tikai ar saviem "saprāta brāļiem". Gints Plivna http://datubazes.wordpress.com

1kārt - visātrāk dara tad, ja neko nedara. Varbūt pusi no vaicājumiem var izmest? Varbūt vismaz tos var nepildīt pie __katras__ ielādes? 2kārt - 1 tabula un 20-30 vaicājumi un būs 50? :O Ciklā lasam kaut ko pēc id??? OK, neko par to nezinot ļoti dīvaini izklausās. 3kārt - 0.09 sekundes, 0.2 sekundes (pieņemot, ka tas ir visiem kopā), tās lietotājam ir tādas visnotaļ netveramas vienības. Varbūt ir vērts koncentrēties uz lietām, kas reāli aizņem vairāk laika, jo pat, ja tās 0,2 sekundes noīsinās līdz 0, būs acīmredzam ieguvums? Tā vien gribās pareklamēt pāris savus ierakstus: http://datubazes.wordpress.com/2007/11/06/kur-paliek-laiks/ http://datubazes.wordpress.com/2011/01/19/darbu-seciba/ Gints Plivna http://datubazes.wordpress.com

Šitais ir raksts par to kāpēc tas ir tā, ja tu lieto wordpresa paša saitu http://wpbtips.wordp...-archive-pages/ Bet vispār īstā atbilde ir šeit. Gints Plivna http://datubazes.wordpress.com/

AFAIK tas visdrīzāk ir atkarīgs no izvēlētās tēmas. Manā blogā (skat zemāk) tā nav. Aizej uz sava bloga admin paneli, paņem kādas tēmas un paskaties, kā tajās izskatīsies tavs garadarbs un kā tam izskatīsies kategroiju lapa. Tur tas ir priekšskatīšanas režīmā, t.i., tas nenozīmē, ka visas tēmas uzreiz rādīsies visiem arī pa taisno skatoties tavu blogu. Gints Plivna http://datubazes.wordpress.com/

http://en.support.wordpress.com/posts/categories-vs-tags/ Gints Plivna http://datubazes.wordpress.com/

Es gan sapratu, ka jāčeko specifiska ieraksta eksistence, kas atbilst noteiktiem nosacījumiem. Pieņemot, ka mums vajag zināt vai eksistē tikai 1 tāds ieraksts, bet nevis to skaitu, tad gadījumos, kad ieraksts var būt tikai 1, tad droši vien count(*) būs pilnīgi OK. Gadījumos, kad tādi ieraksti var būt lielā daudzumā count(*) sanāk tā kā nevajadzīgi par daudz info, jo mums jau vajag tikai nosacītu pazīmi, tāpēc ir vērts atlasīt tiešām reālu pazīmi, piemēram, šādi: select 1 from t where <nosacījumi> limit 1 Tad tiklīdz 1 ieraksts būs atrasts, varēs atgriezt rezultātu un nemeklēt visus pārējos 10, 100 vai miljons ierakstus. Gints Plivna http://datubazes.wordpress.com/

Nu runājot par datubāzēm pirmie un pēdējie ieraksti vispār ir tāds ļoti strīdīgs un nestabils jēdziens. Vienkāršākajā gadījumā, kad tabula ir 1 fails, kas atrodas parastā failu sistēmā un to pēc kārtas lasa cauri, tad tas tā varētu būt. OK es neesmu tik smalki iedziļinājies kā MySQLs fiziski glabā ierakstus (pie tam, cik saprotu, katrai enginei tas var būt savādāk), bet man ir izveidojusies ļoti stingra pārliecība - nekad un nekādā merā nepaļauties uz to, ka DB eksistē kaut kāda predefinēta ierakstu kārtība. Pat, ja šodienas MySQL implementācijā tāda ir, nekur nav teikts, ka tā būs vienmēr un ka vienmēr ieraksti tiks lasīti kaut kādā vienā kārtībā. OK runājot par Tevis doto piemēru, jā šajā gadījumā indekss noteikti varētu palīdzēt, bet šai gadījumā mēs gribam atlasīt tikai vienu mazu daļiņu no visiem lv ierakstiem un, protams, vispārīgi manā augšminētajā izteikumā ir stingri par maz nosacījumu, lai to varētu tā pa taisno pielietot visos gadījumos :) Gints Plivna http://datubazes.wordpress.com/

otrādi - "lv%" Un pareizi būtu teikt - var izmantot. Ja lielākā daļa vērtību sākas ar "lv", tad izmantojot indeksu būs tikai lēnāk. Gints Plivna http://datubazes.wordpress.com/

Norādītā raksta rezultāti nekādi nav salīdzināmi ar to ko piedāvā jautājuma autors. Rakstā tabulas DDL skripts ir šāds: CREATE TABLE cities_varchar ( id int(10) unsigned NOT NULL auto_increment, state varchar(50) NOT NULL, city varchar(255) NOT NULL, PRIMARY KEY (id), KEY state (state) ) ENGINE=MyISAM; Kas nozīmē to, ka uz lauku state ir indekss (norāda atslēgvārds KEY) un tajā ir tikai 1 vērtība - 1 štats. Attiecīgi lasot un filtrējot pēc štata nepieciešamības gadījumā MySQLs var lietot indeksu, ja uzskata to par vajadzīgu, t.i. tam nav obligāti jāpārlasa visi tabulas ieraksti, lai atalasītu nepieciešamos. Autors piedāvā lauku valodas_radit, kas izskatās pēc plika varcahar lauka, kurā vērtības atdalītas ar komatu un meklēt ar konstrukciju LIKE valodas_radit = '%lv%', kur %whatever% nozīmē tikai un vienīgi tabulas pilnu pārlasi (full scan). Kamēr tabulā ir maz datu un maz lietotāju, kas to dara viss ir OK. Ja būs daudz datu vai daudz lietotāju (vai vēl trakāk - abi divi), tad būs milzu bremze. Protams, MySQLā ir visādi tur kešoti selekti un sazin kas vēl, bet, ja būs arī izmaiņas, tad kā minimums pēc katras izmaiņas nāksies visu pārlasīt. Katrā ziņā es nekad nelietotu %lv%. Šis risinājums ir ērts un ātrs, lai vienam dotam rakstam noskaidrotu visas valodas, jo tās ir vienā laukā, bet tas noteikti nav ātrs, lai noskaidrotu visus rakstus vienā dotajā valodā. Gints Plivna http://datubazes.wordpress.com/

Bet nu tikai atceries, ka visi šitādi fona procesi nenozīmē to, ka, ja formā vajag attēlot ierakstus, kam end_time mazāks kā sistēmas datumlaiks, tad tāpēc vari nerakstīt attiecīgu ierobežojumu atlasei. Šādus procesus ir jēga laist ne pārāk bieži, lai vienkārši veco ierakstu skaits neaug bezjēgā, bet jebkurā gadījumā ir jābūt patiesajam biznesa ierobežojumam ierakstu atlasē/apstrādē. Gints Plivna http://datubazes.wordpress.com/

http://datubazes.wordpress.com/category/atrdarbiba/ Pāris lietas: 1) ātrāka ielāde nenozīmē tikai indeksus 2) indeksi var uzlabot (bet var arī neuzlabot) lasīšanas ātrdarbību, bet pilnīgi noteikti pasliktinās datu izmaiņu operācijas. Gints Plivna http://datubazes.wordpress.com

Viss ģeniālais ir vienkāršs :) Tev taisnība. mysql> select com_id, case when com_com_id is NULL then 1 else 2 end as level, com_text -> FROM comments WHERE com_art_id=1 ORDER BY coalesce(com_com_id,com_id),com_id; +--------+-------+------------------------+ | com_id | level | com_text | +--------+-------+------------------------+ | 1 | 1 | pirmais kom | | 2 | 2 | atb uz pirmo kom | | 5 | 2 | otra atb uz pirmo kom | | 3 | 1 | otrais kom | | 4 | 1 | treshais kom | | 6 | 2 | atb uz tresho kom | | 7 | 2 | otra atb uz tresho kom | +--------+-------+------------------------+ 7 rows in set (0.00 sec) Diviem līmeņiem var tiešām šādi. Trīs jau laikam tomēr vairs nevarētu :) Un līdz ar to visādi tur ātrdarbības satraukumi arī izgaist pavisam. Gints Plivna http://datubazes.wordpress.com

Tas vienas tabulas piegājiens arī būs mazliet universālāks tādā veidā, ka teorētiski tajā var glabāt n līmeņus nevis tikai 2. Tiesa gan MySQL piemēram ir lielas problēmas ar šādu rekursīvu vaicājumu veidošanu, bet nu varbūt kādreiz kāds kaut ko darīs šai lietā. Vēl dažas piebilde pie iepriekšējā: - komentāru tabulai tā kā acīmredzit vajadzētu būt saitei uz kaut kādiem rakstiem vai whatever, kas nu tas ir kam tie komentāri pievienoti - lai nebūtu viss jālasa, tad atceramies, ka esksistē taču tāda lieta kā indeksi. Anyway viens no piemēriem varētu izskatīties šādi: Ir tabula komentāri - man tai trūkst kolonas uz lietotāju, bet nu to vari pats izveidot. Un daži ieraksti. mysql> create table comments (com_id int not null auto_increment primary key, -> com_art_id int not null, -> com_com_id int, -> com_text varchar(100)); Query OK, 0 rows affected (0.78 sec) mysql> insert into comments values (1, 1, null, 'pirmais kom'), -> (2, 1, 1, 'atb uz pirmo kom'), -> (3, 1, null, 'otrais kom'), -> (4, 1, null, 'treshais kom'), -> (5, 1, 1, 'otra atb uz pirmo kom'), -> (6, 1, 4, 'atb uz tresho kom'), -> (7, 1, 4, 'otra atb uz tresho kom'); Query OK, 7 rows affected (0.03 sec) Records: 7 Duplicates: 0 Warnings: 0 Rezultātu iegūst šādi: mysql> SELECT com_id, com_com_id, 1 as level, com_text -> FROM comments -> WHERE com_art_id = 1 -> AND com_com_id is null -> UNION ALL -> SELECT c2.com_id, c2.com_com_id, 2 as level, c2.com_text -> FROM comments c1 -> INNER JOIN comments c2 -> ON (c1.com_id = c2.com_com_id) -> WHERE c1.com_art_id = 1 -> AND c1.com_com_id is null -> ORDER BY coalesce(com_com_id, com_id), com_id; +--------+------------+-------+------------------------+ | com_id | com_com_id | level | com_text | +--------+------------+-------+------------------------+ | 1 | NULL | 1 | pirmais kom | | 2 | 1 | 2 | atb uz pirmo kom | | 5 | 1 | 2 | otra atb uz pirmo kom | | 3 | NULL | 1 | otrais kom | | 4 | NULL | 1 | treshais kom | | 6 | 4 | 2 | atb uz tresho kom | | 7 | 4 | 2 | otra atb uz tresho kom | +--------+------------+-------+------------------------+ 7 rows in set (0.00 sec) Tagad veidojam indeksus: mysql> create index com_idx1 on comments(com_art_id, com_com_id); Query OK, 0 rows affected (0.23 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql> create index com_idx2 on comments(com_com_id); Query OK, 0 rows affected (0.19 sec) Records: 0 Duplicates: 0 Warnings: 0 Un skatamies kā tad vaicājums izskatīsies: mysql> explain -> SELECT com_id, com_com_id, 1 as level, com_text -> FROM comments -> WHERE com_art_id = 1 -> AND com_com_id is null -> UNION ALL -> SELECT c2.com_id, c2.com_com_id, 2 as level, c2.com_text -> FROM comments c1 -> INNER JOIN comments c2 -> ON (c1.com_id = c2.com_com_id) -> WHERE c1.com_art_id = 1 -> AND c1.com_com_id is null -> ORDER BY coalesce(com_com_id, com_id), com_id; +----+--------------+------------+------+---------------------------+----------+---------+----------------+------+-------------------------- + | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+--------------+------------+------+---------------------------+----------+---------+----------------+------+-------------------------- + | 1 | PRIMARY | comments | ref | com_idx1,com_idx2 | com_idx1 | 9 | const,const | 3 | Using where | | 2 | UNION | c1 | ref | PRIMARY,com_idx1,com_idx2 | com_idx1 | 9 | const,const | 3 | Using where; Using index | | 2 | UNION | c2 | ref | com_idx2 | com_idx2 | 5 | test.c1.com_id | 1 | Using where | | NULL | UNION RESULT | <union1,2> | ALL | NULL | NULL | NULL | NULL | NULL | Using filesort | +----+--------------+------------+------+---------------------------+----------+---------+----------------+------+-------------------------- + 4 rows in set (0.00 sec) Principā var redzēt, ka nekur full skans (ALL iekš type) tabulām nav. Tas ir tikai rezultātu apvienošanai, no kuras īsti izbēgt šķiet nevar. It kā jau sanāk, ka tos pirmā līmeņa komentārus lasa 2reiz, jo otrreiz tos vajag tikai priekš otrā līmeņa komentāru atrašanas un pēc tam met ārā, bet nu, ja raksta vienkārši left join, tad tie sanāk vienā rindā kopā ar otrā līmeņa komentāriem un tad tos jāķeksē ārā kaut kā programmatoriski. Reālā dzīvē arī tur varētu parādīties vairāki using index, jo šobrīd datu daudzums ir tik mazs (tikai priekš 1 raksta), ka tas īsti neatspoguļo iespējamo realitāti. Gints Plivna http://datubazes.wordpress.com

Nesaku ka tā obligāti jādara, bet tā kā man patīk SQL, tad :) Ja izmanto MySQL, tad tīri mysqlisks risinājums: 1. Izveidojam tabulu 2. Aizpildam 30 rindiņas ar jaunu id, bez nekā cita. mysql> create table u (id int not null auto_increment primary key, -> name varchar(10), surname varchar(10)); Query OK, 0 rows affected (0.08 sec) mysql> insert into u (name) select null from information_schema.global_variables -> limit 30; Query OK, 30 rows affected (0.03 sec) Records: 30 Duplicates: 0 Warnings: 0 mysql> select * from u; +----+------+---------+ | id | name | surname | +----+------+---------+ | 1 | NULL | NULL | | 2 | NULL | NULL | | 3 | NULL | NULL | | 4 | NULL | NULL | | 5 | NULL | NULL | | 6 | NULL | NULL | | 7 | NULL | NULL | | 8 | NULL | NULL | | 9 | NULL | NULL | | 10 | NULL | NULL | | 11 | NULL | NULL | | 12 | NULL | NULL | | 13 | NULL | NULL | | 14 | NULL | NULL | | 15 | NULL | NULL | | 16 | NULL | NULL | | 17 | NULL | NULL | | 18 | NULL | NULL | | 19 | NULL | NULL | | 20 | NULL | NULL | | 21 | NULL | NULL | | 22 | NULL | NULL | | 23 | NULL | NULL | | 24 | NULL | NULL | | 25 | NULL | NULL | | 26 | NULL | NULL | | 27 | NULL | NULL | | 28 | NULL | NULL | | 29 | NULL | NULL | | 30 | NULL | NULL | +----+------+---------+ 30 rows in set (0.00 sec) 3. Kad vajag pieliekt jaunu personu ņemam random 1 rindu, kura vēl ir tukša un iemetam tur personu. mysql> update u set name = 'a', surname = 'a' -> where name is null -> order by rand() limit 1; Query OK, 1 row affected (0.08 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> update u set name = 'b', surname = 'b' -> where name is null -> order by rand() limit 1; Query OK, 1 row affected (0.03 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> update u set name = 'c', surname = 'c' -> where name is null -> order by rand() limit 1; Query OK, 1 row affected (0.09 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select * from u; +----+------+---------+ | id | name | surname | +----+------+---------+ | 1 | NULL | NULL | | 2 | NULL | NULL | | 3 | NULL | NULL | | 4 | NULL | NULL | | 5 | NULL | NULL | | 6 | NULL | NULL | | 7 | NULL | NULL | | 8 | NULL | NULL | | 9 | NULL | NULL | | 10 | a | a | | 11 | NULL | NULL | | 12 | NULL | NULL | | 13 | NULL | NULL | | 14 | b | b | | 15 | NULL | NULL | | 16 | NULL | NULL | | 17 | c | c | | 18 | NULL | NULL | | 19 | NULL | NULL | | 20 | NULL | NULL | | 21 | NULL | NULL | | 22 | NULL | NULL | | 23 | NULL | NULL | | 24 | NULL | NULL | | 25 | NULL | NULL | | 26 | NULL | NULL | | 27 | NULL | NULL | | 28 | NULL | NULL | | 29 | NULL | NULL | | 30 | NULL | NULL | +----+------+---------+ 30 rows in set (0.00 sec) 4. Kad viss ir aizpildīts, tad neviena rinda vairs nemainīsies (pievēršama uzmanību, ka pirms tam bija changed un matched 1, tagad 0): mysql> update u set name = 'a', surname = 'a'; Query OK, 29 rows affected (0.03 sec) Rows matched: 30 Changed: 29 Warnings: 0 mysql> update u set name = 'c', surname = 'c' -> where name is null -> order by rand() limit 1; Query OK, 0 rows affected (0.00 sec) Rows matched: 0 Changed: 0 Warnings: 0 Gints Plivna http://datubazes.wordpress.com

Ieteiktu gan nekādā veidā nefokusēties un nepaļauties uz to, ka tas ir iepriekšējais ID + 1 vai iepriekšējais ID , kam pieskaitīts attālums no zemes līdz mēnesim olektīs mīnus Heopsa piramīdas akmeņu skaits reizināts ar kvadrātsakni no Planka konstantes. Svarīgi ir, ka tas ģenerē unikālu vērtību un dara to ātri nebloķējot (vai minimāli bloķējot) citus šādus pašus pieprasījumus. Gints Plivna http://datubazes.wordpress.com/

Ko nozīmē "labākais"? Tāds jēdziens labākais īsti neeksistē, jo vienam labāks ir tāds, kas ātrāk izpildās, otram tāds ko vieglāk uzporgrammēt, trešajam vēl kaut kas. Domāju, ka gan no programmēšanas viegluma viedokļa (ērtāk un ātrāk uzrakstīt), gan ātrdarbības viedokļa (visdrīzāk strādās ātrāk) labāk būtu rakstīt group by variantu. Ja tur paeeksperimentē ar indeksiem, tad iespējams vispār var izbēgt no visādiem tur filesort un temporārām tabulām izpildes plānā. Bija reiz attāli līdzīgs topiks šeit: http://php.lv/f/topic/16068-count-un-group-by-sadarbiba/ Bet, ja mēs runājam par tādā lietām kā ātrdarbība, tad filozofēšanu tur maz ko līdzēs, vajag vienkārši 1kārts paskatīties izpildes plānus 2kārt dabūt kluci ar datiem un notestēt. BTW ja Tev ir 3 ieraksti 5 rindās un to vaicājumu izpilda 3 cilvēki vienreiz dienā, tad no tāda viedokļa ir pilnīgi vienalga kā to raksta. Gints Plivna http://datubazes.wordpress.com/

MySQL dokumentācija un google ir Tavs draugs. Ja pirmajā linkā pēc šī googles vaicājuma man iedeva vajadzīgo info, kaut gan godīgi atzīstos šo tīri MySQL specifisko f-ju nebiju zinājis. mysql> SELECT SQL_CALC_FOUND_ROWS names.*, category.name -> FROM names LEFT JOIN category ON names.c_id=category.id -> WHERE category.name LIKE '%BBBB%' -> ORDER BY category.name ASC -> LIMIT 2, 1; +------+------+------+------+ | id | c_id | name | name | +------+------+------+------+ | 3 | 2 | CCCC | BBBB | +------+------+------+------+ 1 row in set (0.00 sec) mysql> SELECT found_rows(); +--------------+ | found_rows() | +--------------+ | 3 | +--------------+ 1 row in set (0.00 sec) Otra iespēja, protams ir rakstīt 2 sql teikumus - pirmais vienkārši count(*) select listā bez citām kolonām un bez limit - otrais kā jau sākumā bija. Jā un vēl tā tava pieeja - % priekšā meklējamai simbolu virknei ir absolūts potenciāls ātrdarbības killeris. Nupat vēl pirms mēneša minēju to savā prezentācijā. Nu protams, ja tev ir 5 ieraksti un 3 vaicājumi dienā, tad tas nav svarīgi, bet lielākām lietām silti iesaku tā nedarīt. Gints Plivna http://datubazes.wordpress.com

Paga, bet tad kas tieši tai tavā esošajā vaicājumā nav OK? Jo spriežot pēc tā ko esi uzrakstījis vārdiem un arī SQLā, tie abi sakrīt. mysql> SELECT names.*, category.name -> FROM names LEFT JOIN category ON names.c_id=category.id -> WHERE category.name LIKE '%BBBB%' -> ORDER BY category.name ASC; +------+------+------+------+ | id | c_id | name | name | +------+------+------+------+ | 3 | 2 | CCCC | BBBB | | 4 | 2 | DDDD | BBBB | | 6 | 2 | FFFF | BBBB | +------+------+------+------+ 3 rows in set (0.00 sec) Tiesa gan LEFT [OUTER] JOIN tur ir bezjēdzīgs, tikpat labi varētu lietot arī INNER JOIN, jo ar to WHERE klauzu priekš ārējās tabulas vairs nekāds ārējais savienojums tāpat nesanāk, viss ir kā parasts savienojums. Gints Plivna http://datubazes.wordpress.com P.S. Ā tur figurēja kaut kāds count(*), tikai es īsti neiebraucu kādā veidā un kur tam vajadzētu parādīties?