Min2liz wrote:
SELECT COUNT(dienos) AS `total` FROM `table`

http://www.tizag.com/mysqlTutorial/mysqlcount.php

SUM(dienos)

2

(3 replies, posted in PHP)

aragorna123 wrote:

if(!empty($to) ||!empty($sms) || !empty($amount) || !empty($from) || !empty($operator))

Kas čia per anekdotas?

3

(22 replies, posted in (x)HTML ir CSS)

qutwala, dar kartą paskaityk ką tau rašo:

Min2liz wrote:

...
4. O kam to reikia. nejau pas tave daugiau nei 1K meniu punktų ir daugiau nei 5K lankytojų? Ar tikrai apsimoka tau vargti ir kešuoti jei tikrai nėra tam butinybės?

Jei turi pagrindines programuotojo savybes tai eik ir užsiiminėk kažkokio normalaus produkto kūrimu. Jei ne, tai vargu ar tas dviračio išradinėjimas tau bent kiek padės. Ne tie laikai kai reikia viską nuo 0 daryt. Niekas neturi tiek laiko ir lėšų...

4

(7 replies, posted in PHP)

Nematau reikalo viską perduot vienam kontroleriui. Pirmiausia aprašyt "registracija" route ir visus kitus kas ne kategorijos, o toliau viską perduot kategorijų kontroleriui. Kad vartotojas nesukurtų kategorijos "registracija" galima pačiam ją sukurt. Ji niekada nebus pasiekiama, nes route "registracija" rodo į kitą kontrolerį.

5

(8 replies, posted in PHP)

minde wrote:

http://dev.mysql.com/tech-resources/art … -data.html

Raktažodžiai: hierarchinės struktūros, duomenų struktūros, duomenų medžiai

Ne pirmą kartą matau šią nuorodą, teko ir apsilankyt, bet kai prisireikė ji nebeveikia. Gal kas turite išsisaugojęs kompiuteryje?

6

(6 replies, posted in PHP)

addinol wrote:

nu aš tai čia vieną eilutę ir matau ;Dp

echo date("Hv\a\l i\m\i\\n");
minde wrote:

Taip viskas priklauso nuo to, kaip naudosi. Neteisingai naudojant jokio skirtumo ar PDO ar ne - bus SQL injekcija ir viskas.

Tarkim visos užklausos, kurios dirba su vartotojo duomenimis (GET, POST ir pan.) naudoja PDOStatement. Dalis duomenų perduodama tiesiai, be jokio apdorojimo. Ar tokia sistema yra 99,99% apsaugota nuo injekcijų?

Naudojant PDO injekcijų galima 100% išvengti?

šiandien prisėdau prie šito reikalo. Viską labai paprastai ir greitai sutvarkiau. Viskas veikia. Labai ačiū!

Min2liz wrote:

Nyfyga nesupratau, na bet gal kas pades. Sekmes ;)

Tai pažiūrėk į užklausą su UNION. Iš tos tikrai aišku ko noriu.
Aš klausiu ar tą užklausą galima supaprastinti.

Stengiausi aiškiai paaiškinti ko noriu, bet panašu, kad taip nesigavo.
Kad būtų vaizdžiau, pakomentuosiu rezultatus. Pirmas stulpelis (subkategorijos ID) ir antras (subkategorijos pavadinimas) reikšmės neturi. Trečias stulpelis kategorijos, kuriai priklauso subkategorija ID, ketvirtas reitingas pagal kurį rikiuojame. Rikiavimas ASC.

45 pav 1 1 // tai pirmas įrašas iš kategorijos NR 1. pagal reitingą (1)
48 pav 1 3
65 pav 1 4 // tai rečias įrašas iš kategorijos NR 1. pagal reitingą (4)
49 pav 2 2
72 pav 2 5
56 pav 2 7
67 pav 3 6 // tai pirmas įrašas iš kategorijos NR 3. pagal reitingą (6)
21 pav 3 8 // tai antras ir paskutinis įrašas iš kategorijos NR 3, nes joje tik du įrašai
78 pav 4 9
89 pav 4 10
91 pav 4 12
32 pav 5 11 // kategorijoje NR 5 tik vienas įrašas

Jeigu naudotume UNION, viskas atrodytų taip:

(SELECT * FROM `subkategorijos` WHERE `kategorijos_id` = 1 LIMIT 3) UNION (SELECT * FROM `subkategorijos` WHERE `kategorijos_id` = 2 LIMIT 3) UNION...

Ar įmanoma padaryt kažką geriau negu UNION?

Sveiki,

turim lentelę
subkategorijos(id, pavadinimas, kategorijos_id, reitingas)

Kaip nuskaityti po tris įrašus (arba po tiek, kiek jų yra, jei jų mažiau nei 3) kiekvienai kategorijai pagal reitingą?
T.y. rezultatas turi būt maždaug toks:

45 pav 1 1
48 pav 1 3
65 pav 1 4
49 pav 2 2
72 pav 2 5
56 pav 2 7
67 pav 3 6
21 pav 3 8
78 pav 4 9
89 pav 4 10
91 pav 4 12
32 pav 5 11

Kokie pasiūlymai? Kaip optimaliai nuskaityti reikiamus duomenis?

Pagaliau prisiruošiau padaryti testą. SQL funkcijų greitis stulbinamai mažas. Su PHP tą patį darbą atlieka bent 2 kartus greičiau. Atsižvelgiant į tai, kad PHP rašau OOP, tai SQL bent 3 kartus lėtesnė už PHP. Mėgstu tvarką, bet ne ką mažiau optimalumą, todėl nenaudosiu SQL funkcijų ir procedūrų.

Kaip minde sakė, geriausiai būtų trigeriai, jei turit galimybę juos naudot. (Iki 5.1.6 versijos tam reikalingos SUPER privilegijos).

Ačiū už pagalbą.

EDIT: dar grįšiu prie šito klausimo, nes perdariau laiko skaičiavimo mechanizmą (OOP realizacija) ir gavau kitokius rezultatus. SQL vykdymo laikas krito beveik trigubai. Nelabai suvokiu kaip taip gali būti, nes laiko reikšmės imamoms lygiai tose pačiose vietose.

EDIT2: testą pakartojau. Panašu, kad kažkur buvau klaidą padaręs. Jei į SQL funkciją kreipiatės kelis kartus, tai apsimoka ją naudot (pirmo vykdymo metu reikia dvigubai daugiau laiko nei sekančių).

ValJab wrote:

jeigu neturi super privilegiju tai gali kontaktuoti. :-)))

Gal gali plačiau? Kas tos super privilegijos ir kada jas turi, o kada ne?

--
Rašiau administracijai, bet pralošiau sudėjęs du klausimus į vieną žinutę. Kol vieną atsakė, antrą pamiršo ;)

#1227 - Access denied; you need the SUPER privilege for this operation

Sveiki, gaunu tokį pranešimą kai bandau sukurti trigerį. Naudoju PMA. Funkcijas ir procedūras sukurti galiu.
Kai nurodau DEFINER, ar nenurodau, rodo tą patį.

įmanoma naudotis trigeriais ar reikia kontaktuot su serverio administracija?

Pradėjau testuot procedūros vidurius ir supratau, kad ne tuo keliu nuėjau. Eilutei b bandžiau priskirti eilutės a ID, o ne ranking ir atvirkščiai. (Tas pasako kodėl neveikė testas; kodėl nepavykdavo sukurti proceduros nežinau) Taigi šiuo metu veikianti procedūra atrodo štai taip:

delimiter //
CREATE PROCEDURE `CHANGE_POSSITIONS`(a TINYINT UNSIGNED, b TINYINT UNSIGNED)
 BEGIN
  DECLARE ar, br TINYINT UNSIGNED;
  SELECT `ranking` INTO ar FROM `d_categories` WHERE `ID` = a;
  SELECT `ranking` INTO br FROM `d_categories` WHERE `ID` = b;
  UPDATE `d_categories` SET `ranking` = 0 WHERE `ID` = a;
  UPDATE `d_categories` SET `ranking` = ar WHERE `ID` = b;
  UPDATE `d_categories` SET `ranking` = br WHERE `ID` = a;
 END//
delimiter ;

Manau sutiksit, procedūra atrodo kiek gremėzdiškai, atsižvelgiant į tai, kad ji turi tik sukeisti dvi unikalias (negalinčias dubliuotis) reikšmes vietomis.
Ar įmanoma šioje situacijoje kažką pakeisti, sumažinti užklausų kiekį?

Sukuriu tuščią procedūrą, tačiau procedūrų su užklausom sukurti nepavyksta kodėl? Visada meta #1064 klaidą.
Net tokios procedūros nepavyksta sukurti:

CREATE PROCEDURE GAC() BEGIN SELECT *  FROM d_categories; END

Spėju kad trūksta nedaug, bet kažko esminio.

Sveiki,
galėtumėte pasakyti kas blogai šioje procedūroje?

delimiter //
CREATE PROCEDURE CHANGE_POSSITIONS(a TINYINT, b TINYINT)
BEGIN
      UPDATE `d_categories` SET `ranking` = 0 WHERE `ID` = a;
      UPDATE `d_categories` SET `ranking` = a WHERE `ID` = b;
      UPDATE `d_categories` SET `ranking` = b WHERE `ID` = a;
END//
delimiter;

Kad ir kokius pakeitimus daryčiau visada ją kuriant meta vienodą klaidą (bet procedūrą sukuria; ištestuot neišeina):

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'delimiter' at line 1

Prieš kurdamas visada ištrinu:

DROP PROCEDURE IF EXISTS CHANGE_POSSITIONS;

Situacija panaši kaip rodžiau: http://i50.tinypic.com/291c9og.png
Kaip tai suprast? Kodėl ta eilutė kartojasi?

MySQL versija 5.0.89

minde wrote:

Ten papildomos lentelės lyg nereikėtų, užtektų trigerio AFTER INSERT, kuris paimtų LAST_INSERT_ID() ir padarytų UPDATE tavo norimam stulpeliui tavo turimoje lentelėje.

Tokią idėją turėjau. Bandžiau "gamint" tokį trigerį, bet nepavyko.

minde wrote:

Naudodamas procedūrą tu užklausų kiekio nesumažini, nes jos vykdomos tavo procedūroje. čia tik nebent turi omeny, kad kodas lakoniškesnis (-;

Aš ir nesakiau kad sumažės užklausų :)

Atsiprašau už tokio žemo lygio klausimą, bet kas negerai su mano procedūra CHANGE_POSSITIONS? Kaip ja naudotis?
Dabar einu IF'o ieškot, nes gali būt bėdų kai lentelėj mažiau nei du įrašai. Būsiu dėkingas jei ir dėl šito sulauksiu pagalbos. (if c ne 0 begin .. end)

Gautą nuorodą tikrai panagrinėjau, viskas suprantama, bet nors aš ir ne profesionalas, man atrodo kad šiuo atveju geriau procedūra. Užklausų skaičius tas pats ir nereikia papildomos lentelės, kas man skamba kaip "šuniui penkta koja".

Kodėl kai aš įvedu kodą procedūrai sukurti, gaunu klaidą, nors procedūrą sukuria? Prieš tai buvusią procedūrą ištrinu su DROP. Ir kodėl rodo, kad paskutinė eilutė dubliuojasi? Kartais visas delimiter gabalas dubliuojasi.
Vaizdas: http://i50.tinypic.com/291c9og.png

čia parašiau procedūrą ranking'ams sukeisti.

delimiter //
CREATE PROCEDURE CHANGE_POSSITIONS(a TINYINT, b TINYINT)
BEGIN
  DECLARE c TINYINT;
  SELECT `ID` AS c FROM `d_categories` ORDER BY `ID` DESC LIMIT 1;
  SET c = c + 2;
  UPDATE `d_categories` SET `ranking` = c WHERE `ID` = a;
  UPDATE `d_categories` SET `ranking` = a WHERE `ID` = b;
  UPDATE `d_categories` SET `ranking` = b WHERE `ID` = a;
END//
delimiter;

Tik nelabai išeina ją ištestuoti. Bandau "CALL CHANGE_POSSITIONS(2, 3)", bet gaunu atsakymą "#1312 - PROCEDURE db_table.CHANGE_POSSITIONS can't return a result set in the given context".