Gints Plivna

INSERT INTO party (title, where, text, user_id, date) Nu ja runājam par rezervētiem vārdiem, tad šeit ir 3 gab - where, text, date. Tas ka pēdējos 2 var lietot bez pēdiņām, jo tā daudzi dara, kā pats MySQL savos dokos saka, jau nu patiesībā ir sviests un rāda tikai to, kāds bardaks tur izstrādes sākumos valdīja :) Gints Plivna http://datubazes.wordpress.com P.S. Ā un gribēju piebilst, ka tā ir zināma veida māksla 5 laukos iebāzt 3 kā rezervētos :)

Nu a Tu pamēģināji to 1 AS tips? Kas tieši tam nestrādā? Un BTW iesaku izlasīt par UNION un UNION ALL starpību un lietot tomēr UNION ALL, ko šeit par 99,(9) % vajag ;) Gints Plivna http://datubazes.wordpress.com

from testzzz v1 from v v1 Ar with klauzu definē apakšpieprasījumu v, no kura pēc tam atlasa. Gints Plivna http://datubazes.wordpress.com P.S. Ā un vēl protams jautājums kurš SQL Serveris? Ja kaut kāds aizvēsturisks, tad tur CTE (common table expression) nebija.

Varu tikai pievienoties Alekseja viedoklim, ka nevajag izgudrot divriteni un lietot kaut ko pilnīgi nepiemērotu tam, kam jau sen ir zināms risinājums - datu tips DATE vai DATETIME, vai TIME. Gints Plivna http://datubazes.wordpress.com

ŠIS piemērs ar minimālām modifikācijām strādā arī uz MS SQL. Tiesa gan ierakstu skaita nevājais apjoms apjoms un jautājums kāpēc tas vajag vēl joprojām paliek spēkā. SQL Serverī BTW var izmanto common table expression un tur tas tehniski vispār ir bērnu spēle :) with v as ( select 'q' as n union all select 'w' union all select 'e' union all select 'r' union all select 't' union all select 'y') select distinct (v1.n + v2.n + v3.n + v4.n + v5.n) from v v1 cross join v v2 cross join v v3 cross join v v4 cross join v v5; ----- wwweq wrtwy (7776 row(s) affected) Es gan nemēģināšu nokaut kompi uz visiem piedāvātajiem simboliem. BTW varētu būt visādas problēmas ar temp space, atmiņas apjomu utt. Gints Plivna http://datubazes.wordpress.com P.S. JO TĒMĀ rakstīts RANDOM 5 simboli, bet tekstā prasa visus??? Random nav tas pats kas visi, ne pēc funkcionalitātes, ne pēc ieguldāmā proča/atmiņas resursu apjoma.

Oraclē to var izdarīt ntajos veidos. Bet spriežot pēc sintakses, tas visdrīzāk ir MySQL, kaut gan autors, protams, tādus sīkumus neuzskata par vajadzīgu norādīt ;) Viens piemērs varētu būt šāds: mysql> desc v; +-------+------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+------------+------+-----+---------+-------+ | n | varchar(1) | YES | | NULL | | +-------+------------+------+-----+---------+-------+ 1 row in set (0.01 sec) mysql> select * from v; +------+ | n | +------+ | q | | w | | e | | r | | t | | y | +------+ 6 rows in set (0.00 sec) mysql> select distinct (concat(v1.n, v2.n, v3.n, v4.n, v5.n)) -> from v v1 -> cross join -> v v2 -> cross join -> v v3 -> cross join -> v v4 -> cross join -> v v5 -> limit 20; +----------------------------------------+ | (concat(v1.n, v2.n, v3.n, v4.n, v5.n)) | +----------------------------------------+ | qqqqq | | wqqqq | | eqqqq | | rqqqq | | tqqqq | | yqqqq | | qwqqq | | wwqqq | | ewqqq | | rwqqq | | twqqq | | ywqqq | | qeqqq | | weqqq | | eeqqq | | reqqq | | teqqq | | yeqqq | | qrqqq | | wrqqq | +----------------------------------------+ 20 rows in set (0.00 sec) Tiesa gan tam norādītajam simbolu skaitam variantu skaits ir diezgan iespaidīgs ;) un jautājums ir - ko tad īsti vajag un kādam mērķim kaut ko tādu vispār gribās dabūt? Gints Plivna http://datubazes.wordpress.com

Uzrakstīju (pabeidzu jau sen iesākto) savu versiju arī latviski ;) http://datubazes.wordpress.com/2011/02/15/saglabatas-proceduras/'>http://datubazes.wordpress.com/2011/02/15/saglabatas-proceduras/ Gints Plivna http://datubazes.wordpress.com

Grupēšanas f-jas min, max ir īstā atbilde. mysql> desc ids; +-------+---------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+---------+------+-----+---------+-------+ | id | int(11) | NO | PRI | NULL | | +-------+---------+------+-----+---------+-------+ 1 row in set (0.03 sec) mysql> select max(id) prev from ids where id<5 -> union all -> select min(id) nxt from ids where id>5; +------+ | prev | +------+ | 3 | | 77 | +------+ 2 rows in set (0.00 sec) 1kārt mazāk jāraksta, 2kārt izpildes plāns izskatās labāks (ātrāks) nekā order by .. limit 1 vai iepriekšējā kolēģa ieteiktais. Gints Plivna http://datubazes.wordpress.com

Ar šo piemēru vajadzētu pietikt. Gints Plivna http://datubazes.wordpress.com

Atlasi arī to izteiksmi pēc kuras kārto. Man arī šādi viss notiek: mysql> SELECT article_id, plus, minus, plus-minus -> FROM ( -> SELECT COUNT(CASE WHEN rating = '+' THEN 1 ELSE NULL END) as plus, -> COUNT(CASE WHEN rating = '-' THEN 1 ELSE NULL END) as minus, -> article_id -> FROM ratings -> GROUP BY article_id) as q -> ORDER BY plus-minus DESC; +------------+------+-------+------------+ | article_id | plus | minus | plus-minus | +------------+------+-------+------------+ | 2 | 2 | 0 | 2 | | 1 | 3 | 2 | 1 | | 3 | 1 | 4 | -3 | +------------+------+-------+------------+ 3 rows in set (0.00 sec) un versija - tas varētu būt svarīgi: mysql> show variables LIKE 'version'; +---------------+------------------+ | Variable_name | Value | +---------------+------------------+ | version | 5.1.52-community | +---------------+------------------+ 1 row in set (0.02 sec) Gints Plivna http://datubazes.wordpress.com

Viss strādā šai gadījumā. Iespējams, ka datu tips tabulā nav vis skaitliskais, piemēram, INT, bet simboliskais? mysql> create table q (id int, plus int, minus int); Query OK, 0 rows affected (0.09 sec) mysql> insert into q values (1, 8, 3), (2, 1,2), (3, 3, 6), (4, 1, 1), (5, 2, 4) ; Query OK, 5 rows affected (0.05 sec) Records: 5 Duplicates: 0 Warnings: 0 mysql> select * from q order by plus-minus desc; +------+------+-------+ | id | plus | minus | +------+------+-------+ | 1 | 8 | 3 | | 4 | 1 | 1 | | 2 | 1 | 2 | | 5 | 2 | 4 | | 3 | 3 | 6 | +------+------+-------+ 5 rows in set (0.02 sec) Gints Plivna http://datubazes.wordpress.com

Mmmmm, tad sanāk, ka, piemēram, SQL vai C (bez diviem krustiem) programmētāji ir kreisi programmētāji pēc definīcijas? ;) Vai arī tie darbojas tikai ar pavisam sīkām lietām? Gints Plivna http://datubazes.wordpress.com

Es teiktu diezgan tipisks mūsdienu jauno, moderno un stereotipus lauzošo dzejnieku un prozaiķu darbs... ;) Gints Plivna http://datubazes.wordpress.com

SQL daļa - http://datubazes.wordpress.com/2007/12/28/sql-select-i/'>http://datubazes.wordpress.com/2007/12/28/sql-select-i/ Kā php piemuhļīt klāt nosacījumus, meklē postos šeit pat forumā kaut vai. Gints Plivna http://datubazes.wordpress.com

Nu raksts varbūt tiešā veidā nedod pilnīgi un absolūti skaidru definējumu kāpēc tas ir slikti vai kāpēc tā darīt nevajag. Bet es domāju palasot un mazliet padomājot un piedomājot, kas kur var sanākt, ir tīri labi iegūstama, ja ne tieša atbilde, tad vismaz virziens, kurā es virzu lasītāju ;) Protams, ka tā ir katra individuāla pieeja, tomēr strādājot, piemēram, komandā es ļoti nerekomendēju darīt šādas lietas. Kā arī kā jau rakstā bija minēts ar kolonu nosaukumiem kā f-jām šāda veida nosaukumi vienkārši var novest pie negaidītām un pilnīgi nevajadzīgām kļūdām. Neesmu redzējis nevienu kodu un nevienu projektu, kurā cilvēki būtu sūdzējušies par to, ka kļūdu ir pārāk maz un/vai kods pārāk viegli uzturams, viss pārāk viegli saprotams. Ir vienkārši dažas lietas, par kurām ir vērts piedomāt un no kurām ir vērts izvairīties, lai vēlāk pats neuzkāptu uz sevis nomestā grābekļa. Tāda sapratne BTW nāk ar laiku un strādājot un uzturot ilgtermiņā dažādus koda blāķus. Gints Plivna http://datubazes.wordpress.com

http://datubazes.wordpress.com/2009/01/31/par-objektu-nosaukumiem/

kolonas Jo rindas abi atgriež visas ;) Bet ideja ļoti pareiza, kaut visi tā domātu. Gints Plivna http://datubazes.wordpress.com

Nu bet ļaudis - ir taču tāda lieta, kā vaicājuma izpildes plāns, vai ne? Kuru paskatoties nevajag minēt un teoretizēt kā būtu, ja būtu... Tātad MyISAM tabulai: mysql> create table q (id int primary key) engine=myisam; Query OK, 0 rows affected (0.05 sec) mysql> explain select count(*) from q; +----+-------------+-------+------+---------------+------+---------+------+----- -+------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+------+---------------+------+---------+------+----- -+------------------------------+ | 1 | SIMPLE | NULL | NULL | NULL | NULL | NULL | NULL | NULL | Select tables optimized away | +----+-------------+-------+------+---------------+------+---------+------+----- -+------------------------------+ 1 row in set (0.00 sec) mysql> explain select count(id) from q; +----+-------------+-------+------+---------------+------+---------+------+----- -+------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+------+---------------+------+---------+------+----- -+------------------------------+ | 1 | SIMPLE | NULL | NULL | NULL | NULL | NULL | NULL | NULL | Select tables optimized away | +----+-------------+-------+------+---------------+------+---------+------+----- -+------------------------------+ 1 row in set (0.00 sec) Kas tad tur bija redzams? Tātad MySQL fīča serializēt insertus u.c. darbības ar tabulu šoreiz sevi attaisno pilnā mērā un MyISAM tabulai ierakstu skaitu var dabūt bez vispār jebkādas tabulas vai indeksa pilnas skanēšanas. Bet, ja to pašu izdara innodb tabulai: mysql> create table q1 (id int primary key) engine=innodb; Query OK, 0 rows affected (0.09 sec) mysql> explain select count(*) from q1; +----+-------------+-------+-------+---------------+---------+---------+------+- -----+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+---------+---------+------+- -----+-------------+ | 1 | SIMPLE | q1 | index | NULL | PRIMARY | 4 | NULL | 1 | Using index | +----+-------------+-------+-------+---------------+---------+---------+------+- -----+-------------+ 1 row in set (0.02 sec) mysql> explain select count(id) from q1; +----+-------------+-------+-------+---------------+---------+---------+------+- -----+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+---------+---------+------+- -----+-------------+ | 1 | SIMPLE | q1 | index | NULL | PRIMARY | 4 | NULL | 1 | Using index | +----+-------------+-------+-------+---------------+---------+---------+------+- -----+-------------+ 1 row in set (0.00 sec) Tad redzams, ka abos gadījumos skanē primārās atslēgas indeksu un tādējādi noskaidro tabulas ierakstu skaitu, kā tas arī būs lielākajā daļā DBVSu. Tātad MySQLs vismaz mana konkrētā 5.1.52-community MySQL Community Server (GPL) versija ir pietiekami gudra, lai saprastu, ka primārajā atslēgā NULL vērtību nevar būt un tās visas ir unikālas, tātad count(*) ir identisks count(id). BET tas nemaina lietas būtību tam, ka count(id) VISPĀRĪGĀ GADĪJUMĀ NAV TAS PATS, KAS count(*) un nevajag izmantot bezsakarīgus aizstājējus lietai, kas ir visiem zināma un vispārpieņemta - count(*) parasti lieto un noklusēti visi to saprot kā visu ierakstu skaitīšanu. Un ja ir kaut kas cits, tad DBVS var to saprast tāpat, var arī nesaprast. Kas vēl būtiskāk - citiem cilvēkiem rodas nesapratne - kāpēc tā ir darīts? Vai tam ir kāda jēga, jebšu kāds nodarbojies ar nevajadzīgiem eksperimentiem. Gints Plivna http://datubazes.wordpress.com

sākums http://datubazes.wordpress.com/2008/02/11/sql-join-i/'>http://datubazes.wordpress.com/2008/02/11/sql-join-i/ Visdrīzāk, ka Tev vajag vai nu iekšējo savienojumu, vai ārējo savienojumu. Gints Plivna http://datubazes.wordpress.com

Nu nenormāli šaubīgi tas viss izskatās, apmēram tikpat šaubīgi kā šis selekts :) mysql> desc qwe -> ; +--------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+--------------+------+-----+---------+-------+ | id | int(11) | YES | | NULL | | | adrese | varchar(100) | YES | | NULL | | | col1 | int(11) | YES | | NULL | | +--------+--------------+------+-----+---------+-------+ 3 rows in set (0.03 sec) mysql> select * from qwe; +------+-----------------------------------------------------+------+ | id | adrese | col1 | +------+-----------------------------------------------------+------+ | 1 | "Mezvidi", Barbeles pag., Vecumnieku nov., LV-3905 | 5 | | 2 | "Krievini", Barbeles pag., Vecumnieku nov., LV-3905 | 6 | | 6 | Pionieru iela 6, Bauska, Bauskas nov., LV-3901 | 3 | +------+-----------------------------------------------------+------+ 3 rows in set (0.00 sec) mysql> select id, ifnull(adrese, p), col1 -> from ( -> select id, adrese, p, col1 -> from ( -> select id, adrese, col1, -> substring_index(substring_index(adrese, ',', 2), ',', -1) as p -> from qwe) as q -> group by p, id, adrese, col1 with rollup -> ) as q1 -> where id IS NOT NULL AND adrese IS NOT NULL AND col1 IS NOT NULL -> or id IS NULL AND adrese IS NULL AND col1 IS NULL AND p IS NOT NULL -> ORDER BY p, id; +------+-----------------------------------------------------+------+ | id | ifnull(adrese, p) | col1 | +------+-----------------------------------------------------+------+ | NULL | Barbeles pag. | NULL | | 1 | "Mezvidi", Barbeles pag., Vecumnieku nov., LV-3905 | 5 | | 2 | "Krievini", Barbeles pag., Vecumnieku nov., LV-3905 | 6 | | NULL | Bauska | NULL | | 6 | Pionieru iela 6, Bauska, Bauskas nov., LV-3901 | 3 | +------+-----------------------------------------------------+------+ 5 rows in set (0.00 sec) Gints Plivna http://datubazes.wordpress.com

Nu paga, bet tas taču ir tikai kaut kāds viens attēlošanas veids, kur acīmredzot datus attēlo grupētus pa pagastu/pilsētu? Vai, piedod par izteicienu, Tu tiešām vēlies "izdrāzt datus", lai tiktu galā tikai ar šo vienu reizi, kad Tev šos datus vajag attēlot tieši šādi? Tātad 1kārt šeit būtu jādomā nevis par datu pievienošanu, bet par to kā tos attēlot grupētus vajadzīgajā veidā. 2kārt uz šo brīdi izskatās, ka kārtošana notiek pēc idiem, bet vai tiešām mūžīgi būs tā, ka visi ieraksti jau pēc IDIEM būs grupēti pēc tā pagasta/pilsētās? T.i., kas notiks, ja tālāk ievadīs ierakstu ar id = 11, kuram adrese atkal būs tas bārbeles pagasts? 3kārt cik uzticami ir tas, ka adreses tiek vienmēr pierakstītas šādā formā, ka no otrā līdz trešajam komatam ir tā reālā teksta daļa pēc kuras vajag grupēt? Gints Plivna http://datubazes.wordpress.com

Parastām tabulām nav tāda jēdziena pievienot pa vidu, beigās vai sākumā. Tabulas dati glabājas bāzē kā nu sanāk DBVS tur viņus novietot un pilnīgi nedeterminēti. Tiem NAV NEKĀDAS PREDEFINĒTAS kārtības. Kārtību var iegūt datus atlasot izmantojot ORDER BY klauzu. Visādi citādi arī datu atlasē NEKĀDA KĀRTĪBA NETIEK GARANTĒTA. Šai konkrētā gadījumā mākslīgi protams varētu šādu ierakstu pievienot, bet tas viss izskatās ļoti aizdomīgi - piemēram pirmā kolona izskatās pēc identifikatora, kas parasti normālā gadījumā vienmēr ir aizpildīts, līdz ar to kāpēc tas lai būtu NULL? Labāk paskaidro ko Tev patiešām vajag un kāpēc šādi, iespējams, ka ir citi labāki risinājumi. Gints Plivna http://datubazes.wordpress.com

Šis varētu būt labs sākums: http://en.wikipedia.org/wiki/Software_versioning Gints Plivna http://datubazes.wordpress.com

Tas, par ko Tu runā, saucas klasifikatori :) Var izdalīt vairāku veidu klasifikatorus: Pēc to mainīguma/nemainīguma. - tādus, kuri ir faktiski nemainīgi. Piemēram, dzimums. Parastā DB (kas nenodarbojas ar medicīnisko anomāliju reģistrēšanu) normāli ir 2 dzimumi, nu varbūt vēl trešais, kad nav zināms (vai arī NULL tādā gadījumā). Nav īpaši ticami, ka šīs vērtības mainīsies, maz ticam arī, ka "Sieviete" un "Vīrietis" rīt sauksies kaut kā savādāk. - tādus, kuri laika gaitā var mainīties. Piemēram adrešu sastāvdaļas, visādas tur organizācijas nodaļas utt utjp. Tādas labāk vadīt savā tabulā un likt saites, jo tad klasifikatora izmaiņu gadījumā ir jāmodificē ieraksti datubāzē (kas ir daudz vienkāršāk un iespējams parastam lietotājam), nevis jāmodificē kods. Pēc nepieciešamības kādus no tiem apstrādāt kaut kā īpaši. - piemēram nepieciešamība Latvijas pilsoņus apstrādāt īpaši, t.i., programmā ir jādefinē atbilstoša konstante kurai atbilst Latvijas valstiskā piederība un šādā gadījumā personai ir atsevišķas pārbaudes un/vai biznesa nosacījumi. Šādā gadījumā parasti ir vieglāk definēt konstantes programmā, jo šīs biznesa pārbaudes ir +- predefinētas un jauna pārbaude anyway droši vien nozīmē koda maiņu. - ja ierakstus nekā īpaši nav jāapstrādā, t.i., to apstrāde nav atšķirīga atkarībā no tipa, tad sevišķu jēgu definēt konstantes programmā neredzu, jo tas tikai ierobežo iespēju klasifikatoru koriģēt vai papildināt. Gints Plivna http://datubazes.wordpress.com

Ai nu tabulu nosaukumi kā cipari ir bērna šļupsti. Ja gribam čakarēt sevi un citus, tad daram pa īstam. Gints Plivna http://datubazes.wordpress.com