Gints Plivna

Vienmēr jau nu vajadzētu nenoslinkot un iedot skriptu + piemēra datus. Bet nu es izdarīju pats, jo piemērs likās interesants. CREATE TABLE applications ( id int primary key, email varchar(100)); insert into applications values (1, '[email protected] '); insert into applications values (2, ' [email protected]. '); insert into applications values (3, '[email protected]'); insert into applications values (4, '[email protected] '); insert into applications values (5, '[email protected] '); insert into applications values (6, ' [email protected] '); insert into applications values (7, ' [email protected].'); insert into applications values (8, '[email protected] '); Nu tātad LIKE '%email%' īsti neder, jo tad [email protected] būs tas pats, kas [email protected]. Tāpēc man šķiet, ka vajadzētu uzrakstīt f-ju, kas katru e-pastu noved līdz nosacītai normālformai, lai tur būtu palicis tikai, tas ko vajag, piemēram: mysql> select id, trim('.' FROM trim(t1.email)), email -> from applications t1; +----+-------------------------------+--------------+ | id | trim('.' FROM trim(t1.email)) | email | +----+-------------------------------+--------------+ | 1 | [email protected] | [email protected] | | 2 | [email protected] | [email protected]. | | 3 | [email protected] | [email protected] | | 4 | [email protected] | [email protected] | | 5 | [email protected] | [email protected] | | 6 | [email protected] | [email protected] | | 7 | [email protected] | [email protected]. | | 8 | [email protected] | [email protected] | +----+-------------------------------+--------------+ 8 rows in set (0.00 sec) Un tad jau tālāk var urbt vai nu ar group by: mysql> select trim('.' FROM trim(t1.email)), count(*) -> from applications t1 -> group by trim('.' FROM trim(t1.email)) -> having count(*) > 1; +-------------------------------+----------+ | trim('.' FROM trim(t1.email)) | count(*) | +-------------------------------+----------+ | [email protected] | 4 | | [email protected] | 3 | +-------------------------------+----------+ 2 rows in set (0.00 sec) vai arī group_concat: mysql> select trim('.' FROM trim(t1.email)), group_concat(id) -> from applications t1 -> group by trim('.' FROM trim(t1.email)) -> having count(*) > 1; +-------------------------------+------------------+ | trim('.' FROM trim(t1.email)) | group_concat(id) | +-------------------------------+------------------+ | [email protected] | 1,2,3,4 | | [email protected] | 5,6,7 | +-------------------------------+------------------+ 2 rows in set (0.00 sec) mysql> select trim('.' FROM trim(t1.email)), group_concat(email) -> from applications t1 -> group by trim('.' FROM trim(t1.email)) -> having count(*) > 1; +-------------------------------+----------------------------------------------+ | trim('.' FROM trim(t1.email)) | group_concat(email) | +-------------------------------+----------------------------------------------+ | [email protected] | [email protected] , [email protected]. ,[email protected],[email protected] | | [email protected] | [email protected] , [email protected] , [email protected]. | +-------------------------------+----------------------------------------------+ 2 rows in set (0.00 sec) Ja neder trimi, tad var meklēt patternu <simbols>@<simbols>.<simbols>, bet cik atceros tad vispārīgā gadījumā e-pasta specifikācija bija nenormāli čakarīgs pasākums un gandrīz katrai regulārajai izteiksmei, kas apraksta e-pastu, var atrast kādu piemēru, kas pēc specifikācijas neder :) Gints Plivna http://datubazes.wordpress.com

Gribētu redzēt, kā Tu dabūsi ∞ ekskursantus ;) Es teiktu, ka augšējā robeža teorētiski ir ne vairāk kā iedzīvotāju skaits uz Zemes, bet praktiski krietni mazāks skaitlis :)

Interesanti, gan jau Red Hats aizvāks MySQLu no noklusētās instalācijas. Ņemot vērā faktu, ka Oracle savāca RH Linuxu un uz tā pamata uzbūvēja savējo un faktu, ka jau iepriekš RH tas nepatika, ir tikai loģiski, ka RH un Oracle turpinās sava starpā ēsties. Viss jau galu galā slēpjas naudā, ieņēmumos un to savākšanā vairāk man un mazāk konkurentam. Es varu saprast visus tos argumentus, izņemot absolūtos Open Source zēlotus, kas neatkarīgi no visa cita grib tikai OS, kaut gan domāju, ka 99,9% šo cilvēku tajā sourcē ne reizi pat nav iekšā ieskatījušies, nemaz nerunājot par jebkā mainīšanu. Tas par to argumentu, ka MariaDB ir labāka par MySQL, jo tas vairs nav tīrs Open Source :)

Atļaušos atbildēt. Ir vismaz 2 varianti: 1) Būt pietiekami disciplinētam un kodējot jebkurām shēmas izmaiņām uzreiz rakstīt ALTER skriptus, vai nu citu kas tur nepieciešams. 2) Ja tas kaut kādu iemeslu dēļ nav iespējams, tad var salīdzināt 2 shēmas un manuāli vai automātiski ģenerēt izmaiņu skriptu. Google iesitot compare schema mysql var dabūt optom variantus, sākot jau ar MySQL paša rīku mysqldbcompare. Protams, ka tas prasa uzturēt sākotnējo shēmu (piemēram, kā testa vidi), bet nu puslīdz normāla programmēšanas pieeja to prasa jebkurā gadījumā :)

Ja pareizi saprotu, ka runa ir par db objektu instalāciju, klasifikatoru un konfigurācijas datiem, tad veidojot jaunu db: - db tabulas, indeksi, procedūras, jebkāds cits db objekts - create skripts - dati - insert skripti Taisot patchu: - db objekti - alter, drop, create - dati - update, delete, insert Manā iestādē mēs paralēli uzturam pilnu instalācijas komplektu, t.i., jebkurā brīdī var uztaisīt visu no jauna ar skriptiem, tai skaitā db objektus + sākotnējos kls un konfigurācijas datus. Kopš iepriekšējās versijas izmaiņas kā aprakstīts taisot patchu. Attiecīgi to visu var glabāt jebkurā versiju kontroles rīkā un salīdzināt, analizēt, ko nu katram vajag.

MySQL prezentācijas no Oracle Open World 2013, ja kādam interesē Pieredze liecina, ka tās tur nebūs pieejamas mūžīgi.

Paņem acis pirkstos (pārnestā nozīmē) un paskaties šī foruma šīs sadaļas pirmo tēmu. Gints Plivna http://datubazes.wordpress.com

Es pamēģināju, jo radās interese :) Defaultā jā Access uzrauj pirmo lauku kā PK un autonumber ar to viņa vizuālo brīnumu veidojot jaunu tabulu, bet nekas jau nekavē to PK noraut nost, vai arī izpildīt CREATE TABLE (droši vien, ka tas strādā :). Autoram iesaku beigt cerēt, bet izlasīt kādu grāmatiņu vai pameklēt info inetā un ķerties pie darba pašam. Mamma/Forums Tev visus mājasdarbus nepildīs. Gints Plivna http://datubazes.wordpress.com

Vai tabulā var būt vienādas rindas (ar vienādām vērtībām atbilstošos laukos) Nē Jā, bet ne vairāk kā 2 Jā, bet ne vairāk kā 5 Atkarīgs no lauku skaita Es teiktu, ka neviena atbilde nav pareiza :) Gints Plivna http://datubazes.wordpress.com

Visu vai gandrīz visu var izdarīt SQLā, PHP ir lieks (tas tā fleimam ;) ) Paspēlējos ar MySQL datumu f-jām BTW sākotnējā uzdevumā dati nesaskan ar rezultātu 3 rindiņā, bet tas sīkums. Tātad: mysql> create table t (id int, dep_time time, dep_date date, arr_time time, arr_ date date); Query OK, 0 rows affected (0.03 sec) mysql> insert into t values (1, '18:00', '2012.01.02', '02:42', '2012.01.03'); Query OK, 1 row affected (0.00 sec) mysql> insert into t values (1, '15:00', '2012.01.03', '21:27', '2012.01.03'); Query OK, 1 row affected (0.00 sec) mysql> insert into t values (1, '16:25', '2012.01.04', '16:41', '2012.01.04'); Query OK, 1 row affected (0.00 sec) mysql> select * from t; +------+----------+------------+----------+------------+ | id | dep_time | dep_date | arr_time | arr_date | +------+----------+------------+----------+------------+ | 1 | 18:00:00 | 2012-01-02 | 02:42:00 | 2012-01-03 | | 1 | 15:00:00 | 2012-01-03 | 21:27:00 | 2012-01-03 | | 1 | 16:25:00 | 2012-01-04 | 16:41:00 | 2012-01-04 | +------+----------+------------+----------+------------+ mysql> SELECT SUM(HOUR(diff)) + FLOOR(SUM(MINUTE(diff))/60) as h, -> MOD(SUM(MINUTE(diff)),60) as m -> FROM ( -> SELECT timediff( -> date_add(arr_date, INTERVAL arr_time HOUR_SECOND), -> date_add(dep_date, INTERVAL dep_time HOUR_SECOND)) AS diff -> FROM t) AS t1; +------+------+ | h | m | +------+------+ | 15 | 25 | +------+------+ 1 row in set (0.00 sec) Gints Plivna http://datubazes.wordpress.com

Tas parasti (arī šoreiz) nozīmē tieši vienu lietu - rezervētie vārdi: http://dev.mysql.com/doc/refman/5.6/en/reserved-words.html Gints Plivna http://datubazes.wordpress.com

Hmm, atceros, ka bija reiz jau tāds jautājums un tajā es rakstīju, kas jādara, lai tā būtu ;) Te nu mēs esam :D BTW es šo to arī esmu uzrakstījis latviski par šo tēmu un daži no rakstiņiem ir 1:1 ar tavām problēmām, kuras te diemžēl ir biezā slānī. http://datubazes.wordpress.com/category/atrdarbiba/ Gints

LEFT JOIN favorite ON (event.id = favorite.event_id AND favorite.user_id = <nepieciešamais lietotāja id>) Gints Plivna http://datubazes.wordpress.com

Iekšējā vaicājumā (subquery), Tev ir 4 kolonas ar nosaukumu width un 4 kolonas ar nosaukumu ID. Attiecīgi virsvaicājumā nav skaidrs kuras no tām summēt, attiecīgi vajag aliasot, lai tās visas nesauktos vienādi. Vēl arī īstas jēgas no tiem ID nav, jo atlasot summu 6 ierakstiem, nav vairs principā skaidrs, kura ieraksta ID tad būs tas ņemamais. Gints Plivna http://datubazes.wordpress.com

Neiet gan, jo vispirms nostrādā grupēšanas f-jas un tikai tad LIMIT klauza. Jāliek apakšvaicājumā: SELECT SUM(a), SUM (b) FROM ( SELECT a, b FROM tabula ORDER BY bla LIMIT 6 ) a; Gints Plivna http://datubazes.wordpress.com

Paga es tomēr nesaprotu :O Ja tev vajag katru ierakstu 1 reizi random secībā, tad ar ko tas atšķiras no manis dotā vaicājuma? Tur kā reiz vaicājums atgriež visus tabulas ierakstus, katru 1 reizi un random secībā, es nesaprotu, kas tieši tajā variantā neder? Gints Plivna http://datubazes.wordpress.com

Tur vispār pietiek ar vienu vaicājumu, kas visu darbu paveic jau MySQL galā: SELECT <vajadzīgās kolonas> FROM tabula ORDER BY rand(); Un atrast šo info var šādi: http://lmgtfy.com/?q=mysql+random+order Gints Plivna http://datubazes.wordpress.com

Izdarīt jau var visu ko, bet visdrīzāk, ka korekti būtu glabāt šos 4 ierakstus, kā 4 ierakstus, nevis kaut kādu ar komatiem atdalītu virkni, ar kuru neko jēdzīgu no DB viedokļa nevar pasākt. Tiesa gan, vajadzētu zināt kā šie dati rodas un kā tiek izmantoti, lai pateiktu drošāk. Tad 10 000 vai 1000 ? :) Bet patiesībā tas nav būtiski. Būtiski ir tas - kas tās par kolonām, kas būs tik lielā skaitā? Skatoties uz to tavu sarakstu rodas aizdomas, vai tik tu patiesībā netaisies taisīt kolonas tam, kam būtu jāglabājas katram savā ierakstā? Varbūt vari apstāstīt kas tās par 1K vai 10K kolonām tur būs? Un es gribētu redzēt kā kāds raksta SQL teikumu ar 10 000 kolonām :OOOOO Un atceries, ka normāli SQL teikumus var uzrakstīt ar roku. Pie tam saprātīgā laikā un uzskaitot kolonas, ja vien datu modelis ir korekti izveidots. Gints Plivna http://datubazes.wordpress.com

Interesanti, ka neatradu tādu jauku apkopojošu rakstu ar paskaidrojošiem argumentiem kā un kāpēc eleganti to darīt MySQLā. Es zinu kā to darīt labi un pareizi iekš SQL Server un Oracle (un ir raksti par to), bet cik es saprotu, tad MySQLā īsti nav tāda lieta kā kopējs query kešs ko šārē vairākas konekcijas, līdz ar to var rīkoties, kā teica waplet. - Ir SELECT daļa, kas visiem vienāda, - ir join daļa, ko papildina tad, ja ir netukši kritēriji no citām tabulām, ja kritēriji tikai vienai tabulai tad tādu nevajag - ir where klauza, kuru dinamiski papildina, ja kāds no kritērijiem ir netukšs, lai nebūt jāsatraucās vai pirms tam kāds kritērijs ir bijis vai nē, tad sākumā where klauza = 'WHERE 1 = 1 ' un pēc tam tik netukšajiem kritērijiem met klāt ' AND kolona = $vērtība' - ir order by klauza, kura, ja nevar izvēlēties dinamiski vienmēr ir viena. Tātad mīnuss it kā ir tas, ka katru reizi vaicājumu parsē atkal un atkal, bet nezinu kā to īsti tur risina, un, ja lietotāju nav mega daudz, tad par to var neuztraukties. Pāris relatīvi jēdzīgas tēmas par to pašu problēmu bija šeit: http://stackoverflow.com/questions/7476611/how-to-write-a-query-with-a-dynamic-where-clause http://forums.mysql.com/read.php?52,430828,430945#msg-430945 Gints Plivna http://datubazes.wordpress.com

Es parasti šāda veida problēmas risinu ielādējot datus DB un tālāk jau kā parasti SQLs rullē :) Tiesa gan cik sapratu, šeit tas laikam neietu cauri. No otras puses Oracle ir rakstīta iekš C, tā kā zināma līdzība ar sākotnējo uzdevuma uzstādījumu ir :) Gints Plivna http://datubazes.wordpress.com

The study found that more than 90% of recruiters and hiring managers have visited a potential candidate’s profile on a social network as part of the screening process. And a whopping 69% of recruiters have rejected a candidate based on content found on his or her social networking profiles — an almost equal proportion of recruiters (68%), though, have hired a candidate based on his or her presence on those networks. http://mashable.com/2011/10/23/how-recruiters-use-social-networks-to-screen-candidates-infographic/

Diemžēl latviski neko līdzīgu neatradu :) The Phases of the Disease There are three distinctly noticeable phases in alcoholism. Each phase has its signs and symptoms. · The Early Phase · The Middle Phase · The Chronic Phase The Early Phase · Increased Tolerance: This is the first warning sign of the development of alcoholism. You would need more drinks to get the same pleasurable feeling, which you got earlier with just one or two drinks. · Blackouts: This is not going unconscious or falling flat. During a black out, you may go through many activities like walking, talking, even driving a vehicle ‘apparently normally’, but have no recollection of them afterwards. · Preoccupation with Drinking: Even when you are not drinking, you are preoccupied with when and how you will you can get the next drink. · Avoiding Any Talk About Alcohol: Despite the preoccupation, you do not want to discuss your craving with anybody. Even if you have boasted earlier of you capacity to drink, you want to avoid the subject now. The Middle Phase · Loss of Control: Initially, there is a loss of control over the amount of alcohol consumed. Later on, you lose control over the time, place and occasion of drinking. · Justifying Your Drinking: You feel guilty and depressed. You justify drinking by giving excuses such as unhappy married life, tension at office, pressure from friends to drink, etc. In an attempt to reduce the feeling of guilt, you keep giving different reasons, but your drinking continues. · Grandiose Behaviour: You talk big and spend big; more than you can afford. Quite often, alcoholics in this phase, do not provide even basic needs for the dependent family, but spend what little they have in extravagant gestures among friends. · Temporary Abstinence: By this time, your drinking has lead to plenty of problems, at home and in the office. You are at the point of losing your job and perhaps your marriage. This might make you abstain for a while. · Changing the Pattern: Some make a change in the pattern of drinking. They try to change what they drink; arrack to brandy, whiskey to beer. They try a change of place or time. But so long as it is alcohol, no matter how many changes are made, they continue to be immersed in the same problems that haunted them before. The Chronic Phase This phase is characterised by noticeable physical, mental and social deterioration. There is a total breakdown in relationship with the family. · Binge Drinking: You drink continuously for days together, do not eat and do not involve yourself in any other activity. At the end of each binge you are left shaken, frightened and guilt-ridden, You promise never to drink again. Soon enough you go on another binge. · Ethical Breakdown: You borrow, lie and even steal to keep liquor in supply. You have no qualms about being unethical. Your sole aim is to get enough to drink, whatever the means. · Paranoia and Hallucinations: You begin to suspect people around you with little reason. You imagine they are plotting against you. You may imagine voices speaking to you. You may see things that do not exist or may feel things crawling on you. · Lack of Motor Co-Ordination: Your hand trembles as you hold the coffee cup. Even to shave you have to ‘steady’ yourself with a few drinks. You drink to feel better, but it only makes you feel worse. This is the end of the road. Those who do not stop alcohol consumption even at this stage get mentally ill or die a slow, painful death. No http://knol.google.com/k/the-disease-and-phases-of-alcoholism#

Nu tas ir pilnībā atkarīgs no DBVS arhitektūras. Oraclē tas piemēram tiek realizēts tā, ka katram datu blokam ir atribūts SCN (system change number), kas ir monotoni augošs skaitlis. Katra vaicājuma sākumā tiek nofiksēts kāds ir šis SCNs (teiksim X), tad atlasot datus tiek skatīts kāds ir katra konkrētā datu bloka SCNs, ja tas ir mazāks nekā X, tad šis datu bloks der un dati tiek ņemti no tā. Ja datu bloks jau ir pārrakstīts (kāds cits process to izdarījis), tad iet uz speciālu atmiņas apgabalu, kas saucās UNDO un meklē tā paša bloka iepriekšējās versijas, līdz atrod tādu, kuram SCNs ir mazāks nekā X. Tādā veidā tiek nodrošināts konsistents skats uz dzīvi (t.i. uz to brīdi, kad palaiž vaicājumu), kā arī neviens lasītājs nebloķē rakstītājus un rakstītājs nebloķē lasītājus. Un tātad pēc katras pārrakstīšanas bloku iepriekšējās versijas tiek glabātas UNDO atmiņas apgabalā (vai tai atbilstošā tabultelpā uz diska). Protams, ka šis apgabals ir ierobežots un ar laiku vecās versijas tiek "izēstas" ārā, tādā gadījumā, ja vaicājums vairs nevar atrast pietiekami vecu datu bloka versiju (jo tas ir vilcies pietiekami ilgi un citi procesi ir daudz reizes to pārrakstījuši), tad vaicājums izlido ārā ar tipisku Oracles kļūdu snapshot too old rollback segment XX too small. Vairāk piemēram šeit http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:27330770500351 Bet šis mehānisms ir savādāks katrai DBVS, citām es tik smalki nepateikšu kā tas notiek, jālasa dokos. Piemēram SQL Serverī līdz pat 2005 versijai šķiet bija problemātiski vispār nodrošināt konsistentu lasīšanu, tur bija tiešam iespējamas visādas bloķēšanas vai arī dabūt visādus tādus brīnumus kā Non-repeatable Read u.c. zvēri - sk sīkāk http://sqlserverpedia.com/wiki/Transaction_Isolation_Levels 2005 versijā šis konsistentais mehānisms saucās snapshotizolation un arī tas izmanto speciālu logu (transaction logu), lai uzturētu ierakstu versijas. Gints Plivna http://datubazes.wordpress.com

Vispārīgā gadījumā diez vai. Ja SQLs ir uzrakstīts normāli un gan bāze, gan cilvēks saprot ko un kā dara, tad parasti 1 SQLs strādā labāk nekā ntie, jo sevišķi, ja to dara ciklā. Nu to var pateikt tikai paskatoties izpildes plānu. Zīlēt kafijas biezumos nevajag. Šajā konkrētajā gadījumā, tā kā ir WHERE nosacījumi uz tabulu r_prop, kas it kā ir outer joinota, tad tam left join nav jēgas, patiesībā tas ir tas pats inner join. Līdz ar ko var mierīgi sākt SQL teikumu ķidāt no otra gala t.i. r_prop tabulas, ko MySQLs, kas tomēr ir pieteikami gudrs, arī dara. Kā par to pārliecināties? Tātad vajag izlasīt rakstu par MySQL explain extended :) OK skatamies piemēru izveidoju tabuliņas, ar 2 laukiem katru, id - primārā atslēga + indexus uz id_p kolonām, kas ir kā redzams ārējās atslēgas. un tagad ko mums rāda selekti: mysql> explain extended -> SELECT d.* FROM weight AS d -> LEFT JOIN r_prop AS c ON (c.id = d.id_p) -> WHERE c.id_p = 28 AND c.id = (SELECT MAX(id) FROM r_prop) -> ORDER by c.id DESC; +----+-------------+-------+-------+---------------+-------------+---------+-------+------+----------+------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+-------+---------------+-------------+---------+-------+------+----------+------------------------------+ | 1 | PRIMARY | c | const | PRIMARY | PRIMARY | 4 | const | 1 | 100.00 | | | 1 | PRIMARY | d | ref | weight_idx1 | weight_idx1 | 5 | const | 2 | 100.00 | Using where; Using index | | 2 | SUBQUERY | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | Select tables optimized away | +----+-------------+-------+-------+---------------+-------------+---------+-------+------+----------+------------------------------+ 3 rows in set, 1 warning (0.00 sec) mysql> show warnings -> ; +-------+------+---------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------+ | Level | Code | Message | +-------+------+---------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------+ | Note | 1003 | select `test`.`d`.`id` AS `id`,`test`.`d`.`id_p` AS `id_p` from `test`.`weight` `d` join `test`.`r_prop` `c` where ((`test` .`d`.`id_p` = (select max(`test`.`r_prop`.`id`) AS `MAX(id)` from `test`.`r_prop`))) order by '3' desc | +-------+------+---------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) 1kārt ka redzams, MySQL ir pārrakstījis selektu un taja nav vairs nekāda left join bet ir vienkārši join, tātad inner join. Te nu mēs redzam, ka oriģinālais selekts patiesība ir maldinošs un savukŗat MySQLs ir pietiekami gudrs lai to saprastu un veiktu vaicājuma transformāciju. 2kārt redzam, ka tabula c je r_prop tiek ņemta vispirms un tai tiek klāt joinota tabula weight. Tātad viss ir apgriezts otradi nekā pašā SQL teikumā rakstīts. 3kārt ja palasam googlē ko nozīmē "Select tables optimized away", tad tas nzoīmē to, ka šādu max vaicājumu MySQLs vispār izpilda optimizācijas fāzē un tālāk jau lieto kā konstanti. OK tagad lai redzētu ka left join tomēr mēdz palikt arī left join paskatamies, kas būtu, ja where klauzas nav. mysql> explain extended -> SELECT d.* FROM weight AS d -> LEFT JOIN r_prop AS c ON (c.id = d.id_p); +----+-------------+-------+--------+---------------+-------------+---------+-------------+------+----------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+--------+---------------+-------------+---------+-------------+------+----------+-------------+ | 1 | SIMPLE | d | index | NULL | weight_idx1 | 5 | NULL | 7 | 100.00 | Using index | | 1 | SIMPLE | c | eq_ref | PRIMARY | PRIMARY | 4 | test.d.id_p | 1 | 100.00 | Using index | +----+-------------+-------+--------+---------------+-------------+---------+-------------+------+----------+-------------+ 2 rows in set, 1 warning (0.05 sec) mysql> show warnings; +-------+------+---------------------------------------------------------------------------------------------------------------------------- -----------------------------------------+ | Level | Code | Message | +-------+------+---------------------------------------------------------------------------------------------------------------------------- -----------------------------------------+ | Note | 1003 | select `test`.`d`.`id` AS `id`,`test`.`d`.`id_p` AS `id_p` from `test`.`weight` `d` left join `test`.`r_prop` `c` on((`test `.`c`.`id` = `test`.`d`.`id_p`)) where 1 | +-------+------+---------------------------------------------------------------------------------------------------------------------------- -----------------------------------------+ 1 row in set (0.00 sec) Tātad 1kārt - šai reizē arī versijā ko pilda MySQLs ir left join 2kārt - vispirms iet tabula d jeb weight un tikai tad c jeb r_prop Jebkurā saprātīga bāzē ja lauks ir indeksēts, tad nekur fcauri neiet, bet paņem max vērtību no indexa. Tāpēc lai nebūtu man liekas, vajag pārliecināties kā tad tas notiek patiesībā. Vairumā gadījumu tas ir gan stilīgi gan ātri, ja vien saprot ko raksta, kā raksta un kas jādara lai būtu ātri ;) Gints Plivna http://datubazes.wordpress.com

Politiski iemesli Ticība Konservatīvisms Esošā darbaspēka zināšanas Esošie projekti ar kuriem jāintegrējas Vēlme neieviest/mazināt kompānijas IT zvēru dārzu Ar šiem iemesliem esmu sastapies pats. Gan jau ka ir vēl. Gints Plivna http://datubazes.wordpress.com