Gints Plivna

Yeahh nu mans stāts par to, ka ir process, kas reiz dienā kaut ko dzēš, jau to arī tā kā nozīmēja. Bet, 100 ieraksti, piedod, bet es labu brīdi smējos to ieraugot. OK, nopietni runājot, 100 ierakstu ir ļoti maz, protams, jāatceras, ka datubāzēs eksistē tāda lieta kā indeksi. P.S. Nu kā jau te teica, tad protams, šādu dzēšanas procesu var ielikt arī kādā citā lapā, taču tādā puslīdz nopietnā sistēmā, tas nav labs stils. Gints Plivna http://datubazes.wordpress.com

Patiesību sakot tas, ko Tev vajag, ir ka ieraksti tiek ņemti vērā (attēloti, skaitīti, whatever) tikai tad, ja to vecums nepārsniedz 3 dienas. Tāpēc savā SQL teikumā kur Tu tos atlasi, skaiti vai ko nu dari, pieliec nosacījumu, ka tekošais datumlaiks - ieraksta pievienošanas datumlaiks <= 3 dienas. Jo tādu scenāriju, ka tikko kā izpildās 3 dienas, tā kaut ko dzēš, tas nav reāli, it sevišķi, ja ierakstu skaits ir nopietns. Tad papildus vari pievienot kaut kādu procesu reizi dienā, kas tos ierakstus, kas vecāki par 3 dienām izdzēš, bet jebkurā gadījumā, nosacījums reālajā SQL teikumā (-mos) ir nepieciešams. Gints Plivna http://datubazes.wordpress.com

Skaties group_concat virzienā. Lai nedabūtu divreiz to "liela", lieto distinct, tur norādītajā doka linkā šķiet ir piemērs arī ar to. Gints Plivna http://datubazes.wordpress.com

A kā būtu, ja tu paskatītos šīs pašas foruma sadaļas pirmo piedurto (pinned) tēmu? Gints Plivna http://datubazes.wordpress.com/

Nu kā jau dokā rakstīts vismaz sākotnējais šo mainīgo mērķis ir bijis šāds: You can store a value in a user-defined variable in one statement and then refer to it later in another statement. This enables you to pass values from one statement to another. Bet tad šo fīču izdomas pilni cilvēki izmanto visādām vajadzībām, kuras arī tai pašā lapā zemāk var redzēt un šķiet vairums no tām mainīgos lieto viena selekta ietvaros. Kas jau laikam tomēr vairuma gadījumā arī strādā. Bet iespējas nepareiza lietošana (abuse) jau nav tikai šai konkrētajai MySQL fīčai, tā ir daudz kur :) Bet nu īstenībā šai gadījumā visās citās DB (ok vismaz Oraclē un SQL Serverī), kur tādu mainīgo nav, es lietotu iekļauto selektu ar where klauzu virsselektā. It kā jau MySQLā tā mantra ir, ka apakšvaicājumi ir bremzīgi, bet man ir aizdomas, ka tas itin bieži ir mīts, tāpat kā daudzi citi mīti citās DBVS. Katrā ziņā vismaz ir vērts pamēģināt. Ak jā un vēl vajag atcerēties, ka mainīgie ir konekcijas ietvaros, tātad, ja vienas konekcijas ietvaros to pašu izpilda atkal, jāuzmanās, lai iepriekšējos SQL teikumos inicializētās vērtības nesāk jaukt gaisu... Gints Plivna http://datubazes.wordpress.com

Tur BTW ir kaut kādas acīmredzamas dīvainības kad tie mianīgie tiek un netiek inicializēti. Skat uzskatāms testpiemērs. Man ir tabula t1 kurā ir kolona a, tabulā t1 ir ieraksts ar vērtību 2, bet nav ieraksta ar vērtību 77. Šis testpiemērs īsti nestrādā, kā domāts (vismaz nezinot mainīgo inicializācijas smalkumus), jo viņam vajadzētu atgriezt ierakstu: mysql> select @i := (select a from t1 where a = 77) as k1, -> @j := (select a from t1 where a = 2) as k2, -> @e := coalesce(@i, @j) as k3 -> from dual -> where @e = 2; Empty set (0.00 sec) OK tagad izpildam šo pašu selektu vienreiz bez where klauzas: mysql> select @i := (select a from t1 where a = 77) as k1, -> @j := (select a from t1 where a = 2) as k2, -> @e := coalesce(@i, @j) as k3 -> from dual; +------+------+------+ | k1 | k2 | k3 | +------+------+------+ | NULL | 2 | 2 | +------+------+------+ 1 row in set (0.00 sec) UN TAGAD lai dzīve kā medus nelikto izpildam precīzi to pašu pirmo SQL teikumu: mysql> select @i := (select a from t1 where a = 77) as k1, -> @j := (select a from t1 where a = 2) as k2, -> @e := coalesce(@i, @j) as k3 -> from dual -> where @e = 2; +------+------+------+ | k1 | k2 | k3 | +------+------+------+ | NULL | 2 | 2 | +------+------+------+ 1 row in set (0.00 sec) Bingo! šoreiz ir rezultāts atgriezts! Ļoti jau nu ož pēc tā ka pirmā SQL teikumā tomēr @e netika izrēķināts, tb vispirms bija where klauza, kas visu jau nogrieza nost. Tad otrā SQL teikumā @e tika izrēķināts, jo where klauzas vispār nebija. Tad trešajā SQL teikumā jau izmantoja to pašu @e, kas jau bija izrēķināts otrā SQL teikumā. Un galu galā jālasa MySQL dokumentācija, jo tur jau patiesība viss ir rakstīts: As a general rule, you should never assign a value to a user variable and read the value within the same statement. You might get the results you expect, but this is not guaranteed. The order of evaluation for expressions involving user variables is undefined and may change based on the elements contained within a given statement. In SELECT @a, @a:=@a+1, ..., you might think that MySQL will evaluate @a first and then do an assignment second. However, changing the statement (for example, by adding a GROUP BY, HAVING, or ORDER BY clause) may cause MySQL to select an execution plan with a different order of evaluation. Gints Plivna http://datubazes.wordpress.com

Ja godīgi, maz ko zinu par MySQL mainīgajiem, bet vai šai gadījumā nav tā, ka vispirms tiek izpildīta where klauza un tad tikai iniciēts mainīgais @has_vendor_id. Līdz ar to ir vismaz 2 iespējas, manuprāt: 1) rakstīt nosacījumu uz individuālajiem mainīgajiem, jo coalesce jau ir tikai f-ja un to var gana viegli nosimulēt papildus where nosacījumos ar mazliet garākiem AND/OR nosacījumiem 2) rakstīt virsselektu, kuram subselekts ir šis te jau dotais (iespējams bez SQL_CALC_FOUND_ROWS, kuru var iznest virsselektā) un where klauzu pielietot virsselektā, kur @has_vendor_id jau būtu jābūt izrēķinātam. Gints Plivna http://datubazes.wordpress.com

Nu ja kaut kas iet lēni, tad pirms vispār sākt drudžaini meklēt risinājumus, ir jānoskaidro kas bremzē Gints Plivna http://datubazes.wordpress.com

otro rindiņu var dabūt šitā: SELECT resp_code, row_num, [1], [2], [3], [4], [5] FROM a PIVOT (SUM (cvalue) FOR cnr IN ([1], [2], [3], [4], [5])) AS p Par pirmo nav īsti skaidrs vai tā ir fiksēta, vai kā, un kā vispār tos rezultātus vajag, ja vairāki resp_code, row_num utt. Gints Plivna http://datubazes.wordpress.com

neticēsi, bet es pats šo sintaksi no galvas nezinu, man pašam būtu jāpēta šie linki un dotajā brīdī ir citas svarīgākas lietas ;) Tā kā ņem vien pats un pēc analoģijas uzcep SQL teikumu no rakstos minētajiem piemēriem Gints Plivna http://datubazes.wordpress.com

Using PIVOT and UNPIVOT The PIVOT Operator Gints Plivna http://datubazes.wordpress.com

Pasaulē ne tuvu nav tikai viena datubāze un SQLs arī starp tām diezgan pamatīgi atšķiras (jo sevišķi šādām fīčām), tā kā stikla bumbas mums nav, tad vajadzētu minēt, kas tā par DB. Gints Plivna http://datubazes.wordpress.com

Formatējot. Un to var izdarīt gan SQL Server galā, gan php galā. Tikai ar tik triviālām tak spēsi galā tikt pats, vai ne?`;)

SELECT TOP 10 cnt, cnt/cast(total as float)*100 AS per_cent, country Kolonas: cnt - skaits per_cent - noaliasoju, procenti country - valsts Principā jau nu nekas īpaši sarežģīts tur nav, vismaz kolonas aizstājējvārdu (alias) vajadzētu mācēt pielikt, tas rakstīts piemēram šeit http://datubazes.wordpress.com/2007/12/28/sql-select-i/'>http://datubazes.wordpress.com/2007/12/28/sql-select-i/ Gints Plivna http://datubazes.wordpress.com

Lasīt mākam? Nu tad sākam! ;) Tas ko Tu esi uzrakstīji savā php kodā nav tas ko es tev uzrakstīju. Šeit nav daiļliteratūra un cnt un country ir 2 dažādas lietas. Procentuāli (pirmā kolona skaits, otrā procents, trešā valsts): SELECT TOP n cnt, cnt/cast(total as float)*100, country FROM ( SELECT count(*) cnt, country FROM tabula GROUP BY country ) as t CROSS JOIN ( SELECT COUNT(*) total FROM tabula ) as t1 ORDER BY cnt DESC TUR TAGAD IR 3 KOLONAS un arī PIRMS TAM BIJA 2, no kurām vienā bija skaits Gints Plivna http://datubazes.wordpress.com

Aga tikai zinātnieki par to vēl joprojām strīdas: http://www.seo-theory.com/2007/09/05/how-to-screw-your-web-site-with-nofollow/ http://www.searchenginejournal.com/nofollow-an-seo-red-flag/6354/ http://www.mattcutts.com/blog/pagerank-sculpting/ Es par laimi neesmu SEO speciālists un varu brīvi paust savu nespeciālista viedokli, ka manuprāt tas ir bezsakars, tāpat kā dietologi par zupām, vieni saka, ka zupas jāēd, citi saka, ka tās esot indes ;) Gints Plivna http://datubazes.wordpress.com

select top n count(*) cnt, country from tabula group by country order by cnt desc n - cik ierakstus gribi redzēt select count(*) from tabula where datuma_lauks > DATEADD(dd, DATEDIFF(dd,0,GETDATE()), 0) otrais izskatās nenormāli tizli, piekrītu, bet AFAIK SQL Serverī nav normāla veida kā eleganti nogriezt laika daļu datumam Gints Plivna http://datubazes.wordpress.com

Nu lūk vēl ir ļoti vēlams iemācīties atrisināt pašam šādus elementārus jautājumus, jo acīmredzot tādi radīsies ne viens vien ;) Veids, kā es meklēju saiti, ko Tev parādīt bija šāds: google->matrica->vikipēdija latviski->secinām, ka tur nekā jēdzīga nav->spiežam uz linka angliski-> iegūstam http://en.wikipedia.org/wiki/Matrix_(mathematics) Vēl tāda lieta - ir jāzina vismaz tehniskā līmenī lasīt angļu (vai iespējams krievu, zinu, bet primāri meklēju visu angliski) valodā, jo latviski ir ļoooooti minimāli resursi, un tie labākā gadījumā noder varbūt, lai universitātē nokārtotu pamata uzdevumus, bet nekādā ziņā, lai apgūtu kaut ko nopietnā līmenī vai profesionāli nodarbotos ar programmēšanu. Pēc paša pieredzes varu teikt, ka, ja normāli ir apgūta un nav īpašu problēmu ar matemātiku skolā, tad LU arī tas turpinās :) Vienīgais priekšmets, kas man personīgi dziļi riebās un ko es sapratu tikai puslīdz tai brīdī, kad taisni klausījos, bija matemātiskā analīze, bet nu tas noteikti ir ļoti individuāli. Gints Plivna http://datubazes.wordpress.com/

Nu precīzi tautu staigāšana ērti uzskatāmā veidā pēdējās 2 Saeimās ir redzama šeit. Kā redzams ZZs ir VISU laiku sēdējusi valdībā, bet šos par krīzi neviens nevaino :O Kā jau te viens kolēģis precīzi minēja, prot klusiņām piesmērēties un nelīst priekšplānā, ja neskaita pārpratumu Emsi ;) Praktiski visu laiku, izņemot pēdējo gadu, tur ir sēdējuši arī LPP. Jaunais laiks bija gadu un 4 mēnešus pašā sākumā un tagad atkal. Ā un ieskatoties uzmanīgāk arī stabilitātes garanta pirmajā valdībā kādu gadu vai drusku vairāk šie bija. Gints Plivna http://datubazes.wordpress.com

Nu te es redzu 2 variantus: 1) ja lietotājam nejauši aizsitas logs un viņš pats pēc tam to ver vaļā atkal - tad progza pārbauda, kas ir rezervējis un ja tas ir viņš pats, tad rāda viņa esošo rezervāciju skaitu un stāvokli. 2) ja lietotājam nejauši aizsitas logs un kāds cits pēc tam uzreiz grib dabūt to preci, tad ir apmēram tā kā senos laikos, kad uz preces uzlikta lapiņa "rezervēts" un citi to kādu laiku neņem nost. Vēl labāk būtu, ja uz lapiņas būtu uzrakstīts arī kurš rezervējis - tad citi varētu akūtas nepieciešamības gadījumā viņam zvanīt un prasīt - vai tev tiešām vajag? To varētu arī tikpat labi nosimulēt šādā sistēmā, kur Jānim pie iespējām rezervēt piena pakas parāda, ka var dabūt 5 gab, bet 3 jau ir rezervējis Andris un 5 Anna. Attiecīgi, ja Jānim traki vajag vairāk nekā 5, tad viņš zvana Andrim un/vai Annai un prasa vai tev tiešām to vajag? Var protams arī ielādējot lapu sākumā rezervācijas dzēst, bet tad to relatīvi droši var darīt tikai tekošajam lietotājam, jo citu lietotāju rezervācijas (vismaz jaunās) dzēst ārā būtu galīgi nekorekti. Pie tam tādā gadījumā, ja nejauši kaut kas aizsitas ciet, visas rezervācijas atkal jāsāk no sākuma. >Jo man nerāda ierakstut kur vienību skaits ir 0. Nu pieņemu, ka to var koriģēt un ja visas preces ir tikai rezervētas, bet nav pārvietotas, tad to kaut kā speciāli arī rādīt, ar piemēram, to augšminēto info, kurš rezervējis.

Izklausās pēc tādas kā preču rezervācijas. Nu arī dabā lielākoties rezervācija strādā zināmu laiku - stundu, dienu vai vairāk, pēc tam resurss nonāk atpakaļ kopējā čupā un ir atkal visiem pieejams. Tātad viena no iespējām varētu būt šai tabulā B pielikt klāt laiku, kad prece rezervēta un kurš to izdarījis (lietotājs vai sesija - atkarībā no nepieciešamības un iespējām). Ja lietotājs ir to logu vienkārši aizsitis ciet, aizgājis dzert kafiju vai viņam nokāries kompis, tad viņš šo rezervēšanas laiku neatjaunos un attiecīgi jāpieliek klāt periodisks procesiņš, kas ik pa kādam brīdim (piem reizi stundā, vai biežāk, cik nu vajag) dzēš no tabulas B pārāk vecos ierakstus. Gints Plivna http://datubazes.wordpress.com

Tieši tā, visu šo konstrukciju (identity, autoincrement, sequence) galvenā jēga ir ģenerēt UNIKĀLAS vērtības. Tas, ka tās tiek ģenerētas pēc kārtas parasti palielinot par 1 (BTW vairumā gadījumu to var modificēt un reizēm pat to ļoti vajag) ir blakus efekts un nekādā ziņā nekad nevajadzētu mēģināt šādā veidā iegūt skaitļus, kas palielinās par 1 un ir bez caurumiem. Gints Plivna http://datubazes.wordpress.com

Nu nu... http://www.google.lv/search?sourceid=chrome&ie=UTF-8&q=natural+vs+surrogate+keys

Nu es tā neteiktu. Tātad pirmkārt arī dabiskā veidā vienu objektu var unikāli identificēt vairākos veidos, piemēram, personu 1) pēc personas koda, 2) vārda, uzvārda, dzimšanas datuma un dzīvesvietas. Tātad ja kādā sistēmā veidos personu tabulu ar ģenerētu id, tad UK uz personas kodu neveidos? Tad pastāv risks, ka kāds ieplēsīs divus tādus. Atceramies, ka ierobežojumiem un tiem atbilstošiem indeksiem ir 2 veidu funkcijas: 1) nodrošināt potenciāli labāku ātrdarbību 2) nodrošināt datu integritāti, piemēram, to, ka noteiktā(-s) kolonā(-s) dati ir unikāli. Un dažkārt var gadīties, ka šim gadījumam no ātrdarbības viedokļa nav jēgas, bet datu pareizības ir. Un tad lielajā vairumā gadījumu, tā ir svarīgāka.

Pirmkārt tabulai nevar būt vairākas primārās atslēgas, bet tikai viena. Visas pārējās ir jāveido kā unikālās atslēgas. Attiecībā uz "pareizāks un labāks" nav vienota akmenī iecirsta veida tāpat kā vienam patīk māte, otram meita, trešajam kleita. Viss atkarīgs no kāda skatu punkta skatās, piemēram: - ja raksta savienojumus (join) starp šādām tabulām, tad jo vairāk kolonas, jo savienojuma nosacījums kļūst neērtāks un lielākas iespējas ielaist kļūdas - ja bērna tabulā ļoti bieži vajag dabūt vecāka tabulas kolonas A, B, C un citu neko nē, tad savukārt ir izdevīgi, jo tās kolonas jau ir iekšā bērna tabulā un nav jātaisa lieks savienojums izmantojot ģenerēto ID lauku. - ja kādreiz pastāv iespēja, ka lauki A, B, C var mainīties, tad PK gadījumā no 3 kolonām, jārēķinās, ka tās būs jāmaina visur. Īsāk sakot tas ir mūžīgais jautājums naturālās atslēgas vai surogātatslēgas (ģenerētās atslēgas). Īsumā, ja neskaita ļoti speciālus gadījumus, es balsoju par surogātatslēgām (tātad ģenerētiem id laukiem), bet esmu pārliecināts, ka ir cilvēki, kas domā pretēji :) Gints Plivna http://datubazes.wordpress.com