Claudiu Persoiu

Blog-ul lui Claudiu Persoiu


Archive for the ‘MySQL’ tag

Oracle cumpara Sun – un nou episod

without comments

Se pare ca Oracle a primit aprobarea de la EU pentru a cumpara Sun conform Yahoo! News.

Acum aproximativ un an jumatate ma gandeam sa sustin examenul pentru MySQL Certified Developer. Acum dupa ce am devenit Sun MySQL Certified Developer se pare va voi deveni Oracle MySQL Certified Developer. Si toate acestea fara nici un ban in plus! 🙂

Partea buna este ca vom ajunge sa lucram cu Oracle chiar si fara voia noastra (ok, nu e chiar Oracle, dar e un produs al lor).

Written by Claudiu Persoiu

26 January 2010 at 9:57 PM

Posted in Diverse,MySQL

Tagged with , ,

A mai trecut un an iar PHP 6 tot nu este aici…

without comments

A mai trecut un an iar PHP 6 tot nu e aici…

Dar asta nu este tocmai o noutate, este al 4-lea an in care aceasta versiune mult asteptata nu se lanseaza, nu degeaba este numita cea mai asteptata versiune.

Totusi a fost un an bun pentru comunitate, chiar daca Unicode nativ nu exista inca intr-o versiune stabila, acum avem cam toate celelalte noutati asteptate in PHP 5.3, care probabil va mai avea nevoie de cativa ani ca sa devina folosit pe scara larga.

Chiar daca toata lumea astepta in acest an ca Oracle sa intre in forta pe piata de baze de date medii si mici prin achizitia Sun, marind portofoliul deja detinut pe piata enterprise. Se pare ca nu a fost asa, CE inca analizeaza propunerea.

Oricum MySQL nu mai este ce era acum 5-6 ani, cand nimeni nu indraznea sa-l foloseasca pentru produse enterprise, acum MySQL este un produs gata pentru a fi folosit atat pentru proiecte mici cat si pentru produse care necesita muta scalabilitate.

Dar revenind la anul care tocmai s-a incheia, a fost un an plin, chiar si in timp de criza.

Written by Claudiu Persoiu

13 January 2010 at 8:30 AM

Posted in Diverse,MySQL,PHP

Tagged with , ,

Bad code si framework-uri

without comments

De ce se vorbeste atat de “bad code” sau “bad practices”? Pentru ca sunt importante!!!

In ultima vreme am avut parte de o experienta care eu o consider neplacuta, cod necomentat, design slab, oop prost implementat, baze de date neoptimizate si prost proiectate.

Comentarile

Este un mare mister pentru mine cum se poate ca in fiecare carte si tutorial disponibil (nu doar de PHP) scrie ca acestea nu sunt optionale ci NECESARE si totusi acestea de cele mai multe ori lipsesc cu desavarsire. Zend Studio are un auto-complete forte simplu si eficient, nu trebuie sa scrieti decat “/**” si sa apasati enter, apoi textul care apare trebuie completat. Netbeans la fel, acelasi sistem, la fel de simplu.

Cu toate astea in ultima perioada m-am lovit de mii de linii de cod aproape fara nici un comentariu, rezultatul? Ore intregi pierdute incercad sa urmaresc logica!

De ce se intampla asta? Primul motiv: este plictisitor, un programator vrea sa scrie cod nu povesti, de multe ori pare un timp irosit. Al doilea motiv: totul pare foarte logic in momentul in care este scris, daca este atat de logic si cursiv de ce sa mai pierzi timpul cu povesti? Pentru ca timpul trece, proiectele se schimba, in timp inevitabil, toata logica este data uitarii. Sau un alt motiv, pentru ca vin persoane noi, in firme programatorii vin si pleaca, iar cel care vine nu mai poate urmarii logica cu aceeasi usurinta, de fapt de multe ori este aproape imposibil de urmarit. Am patit chiar si ca autorul codului sa nu o mai poata urmarii dupa o anumita perioada de timp, uneori autorul eram chiar eu.

Dupa parerea mea asta ar trebui sa fie o regula de baza pentru orice firma care se respecta, nici o clasa/metoda/proprietate nu trebuie sa fie necomentata. Timpul priedut acum pentru comentarii este timp castigat mai tarziu cand se face debugging, oprimizare etc.

Design slab

Am vazut la un “mini interviu” on-line o intrebare care suna: “vedeti importanta arhitecturii inainte de a scrie cod?”, imi cer scuze daca nu mai suna la fel ca in anunt. Prima data cand am vazut intrebarea am avut un moment de deja-vu, de multe ori m-am lovit de problema de a scrie cod ca mai apoi sa realizez ca am o abordare gresita.

De multe ori problema asta se rezolva (cel putin aparent) in timp cu experienta. Practic, daca iei un incepator si il pui sa scrie cod, cel mai probabil va avea cateva abordari slabe pana sa aiba una reusita, iar asta nu este de loc anormal, de asta cred ca un incepator ar trebui ghidat inainte de a incepe sa scrie cod, iar codul care urmeaza sa-l scrie sa aiba o logica clara sugerata de un “mentor”.

In cealalta extrema exista “software architects” care folosind UML schematizeaza logica si structurile in diagrame. Cand exista diagrame atunci este mult mai ushor de urmarit intregul proces si intreaga structura a aplicatiei. Un arhitect priceput va putea sa vada problemele posibile care pot aparea inainte de a incepe sa scrie cod, iar cand se incepe implementarea fiecare stie ce are de facut.

OOP-ul se loveste probabil cel mai mult de design-ul slab, in ultima vreme am vazut o multime de clase care nu aveau nici un fel de organizare, erau doar simple invelitori (wrappers) pentru interogari SQL. Asta nu inseamna OOP!

OOP presupune abstractizarea elementelor in clase si obiecte. De exemplu tastatura, aceasta este o clasa care are niste taste (o clasa copil) cu diverse proprietati(litere, cod de tasta, pozitie), niste leduri (alta clasa copil) etc. Repezentarea acestora in baza de date nu are neaparat o legatura atat de stransa cu obiectele cum pare la prima vedere.

Daca folosesti OOP iar ce citesti acum suna bizar, incearca sa faci pe o foaie de hartie o diagram a aplicatiei tale cu obiectele si a legaturilor dintre ele. Daca nu poti, inseamna ca abordarea ta fata de OOP este gresita(sau nu sti sa faci o diagrama 🙂 )!

Toti facem greseli cand vine vorba de OOP, dar asta nu este o scuza sa nu le corectam si sa nu incercam sa facem arhitectura inainte de a scrie cod.

Un design prost de aplicatie poate avea repercusiuni foarte importante financiare. Timpul inseamna bani, iar daca o aplicatie este slaba, nu este bine structurata, timpul pentru debug-ing este mare, schimbarile necesita timp indelungat, redundanta codului este mare, etc., atunci poti fi sigur ca pierzi bani.

O unealta pe care o folosesc uneori este Violet UML Editor, nu este un editor adevarat de UML cum este Rational Rose de exemplu, ci mai degraba o jucarie open source. Cu Violet se pot realiza doar diagrame vizuale, dar ele pot fi utile pentru a structura o aplicatie.

Baze de date

Oare de ce se feresc multi programatori PHP sa invete cu adevarat MySQL? Suna bizar? Este foarte adevarat totusi. Modificarea codului PHP este de multe ori o operatie nu foarte dificil de realizat (ma refer la rescrierea practica a codului), dar un design prost al bazelor de date este de cele mai multe ori mult mai dificil de modificat pentru ca exista riscul sa piezi informatii.

Acum cateva saptamani am facut o diagrama a unei baze de date folosind MySQL Dump si MySQL Workbench. Nu mica mi-a fost surprinderea sa vad tabele care nu aveau chei de legatura cu alte tabele din care proveneau date (nu ma refer la tabele de setari care din punct de vedere logic nu se leaga), apoi sursa datelor era complet pierduta.

O alta problema clasica de incepatori este cand ai o tabela de legatura intre doua tabele cum ar fi categorii si produse, iar cheia este pusa pe un camp cum ar fi “id” care nu are nici o relevanta. O cheie primara se poate pune pe mai multe campuri, de exemplu cheia ar trebui sa fie “id_categorie, id_produs” nu “id”, iar in felul asta se asigura si unicitatea unui produs intr-o categorie folosind restrictia de primary key.

Un alt lucru care nu il inteleg este de ce lumea evita indecsii. Intr-un blog anterior vorbeam pe scurt despre ei, complet insuficient dar totusi sunt foarte importanti. Un index poate micsora semnificativ timpul de cautare intr-o tabela, de la zeci de secunde uneori la sutimi de secunda. O aplicatie prost optimizata din punctul asta de vedere poate avea un timp de raspuns semnificativ mai mare decat este normal.

Framework-uri

Ca sa citez o fraza deja clasica in comunitatea PHP:

All frameworks suck.

iar Laura Thomson are niste motive destul de bune cu care sa sustina asta.

Cineva spunea saptamana trecuta ca motivul pentru codul prost este chiar PHP si modul lui permisiv. Sa fim seriosi, daca luam un limbaj ca C++ are mult mai multe probleme care pot aparea. Imi aduc aminte in facultate cat de slab era codul care il scriam, iar problema nu era limbajul ci nivelul meu de pregatire de atunci. PHP permite abordari de la OPP pana la spaghetti code (OOP, proceduri, closures, label-uri). Faptul ca multi programatori aleg abordarea proasta nu este o problema de limbaj, la fel exita o problema de abordare si in limbaje cum ar fi C++, sau mai bine zis in orice limbaj exista.

De ce sunt mai putine probleme de design in Ruby on Rails de exemplu? Pentru ca este un framework! Eu nu am auzit pe nimeni pana acum sa faca programare web doar in Ruby (exista programatori Ruby, in special pentru aplicatii desktop, dar asta este alta discutie), evident ca apar mai putine probleme cand folosesti un framework. La fel se pot reduce si probleme din PHP folosind un framework consacrat.

Exista zeci sau chiar sute de framework-uri open source pentru PHP. Din acesta exista cateva cu adevarat consacrate, cum ar fi Zend Framework, CakePHP, Symfony, Solar, CodeIgniter etc. Un avantaj major atunci cand se foloseste un framework este ca poti gasi mult mai usor persoane specializate. Un alt avantaj major este ca ai parte de un cod testat si documentat, lucru care este deosebit de dificil de realizat intr-o firma de dimensiuni reduse.

Sau chiar daca se foloseste un framework intern cred ca este utila abordarea unei structuri similare cu un framework consacrat pentru a reduce curba de invatare pentru programatorii noi.

Folosind un framework consacrat de multe ori se reduce timpuri de lucru si timpul de dezvoltare de noi faciltati pentru ca de multe ori acesta sunt incluse, deci pot aparea avantaje economice indirecte (bani), o stucturate mai buna si nu in ultimul rand programatori mai fericiti (cea ce nu sunt eu acum).

Concluzionand:

  • stabileste niste reguli interioare pentru cod, nu uita sa pui comentarile pe lista,
  • asigura-te ca designul aplicatiei este facut conform unui plan care sa permita scalabilitate si o redundanta minima a codului,
  • asigura-te ca baza de date este bine structuata si optimizata,
  • ia in calcul folosirea unui framework consacrat fata de un framework intern sau de unul nou conceput.

Folosind aceste reguli simple se vor salva resurse, timp, bani iar programatorii vor fi probabil mai multumiti de rezultate.

Written by Claudiu Persoiu

4 October 2009 at 2:07 PM

Posted in MySQL,PHP

Tagged with , ,

MySQL si Unicode folosind UTF-8

without comments

O data cu globalizarea, batranul cod ASCII nu mai este potrivit. Ganditi-va ca intr-o buna zi trebuie sa dezvoltati un proiect in germana, rusa sau chiar japoneza, puteti adapta characterset-ul pentru fiecare din aceste limbi sau puteti pur si simplu sa-l dezvoltati folosind Unicode.

Pentru a folosi Unicode cu MySQL se poate folosi UTF-8.

Trebuie sa retineti ca caracterele UTF-8 au o marime variabila si sunt compatibile ASCII. In ASCII 1 caracter = 1B, in UTF-8 1 caracter poate avea intre 1 si 4 B.

Charset si collation UTF-8 pe server

In MySQL tipul caracterelor este dictat de charset.

Pentru a vedea daca este instalat pe server:

SHOW CHARSET LIKE 'utf8';

sau cu information_schema

SELECT * FROM `CHARACTER_SETS` WHERE CHARACTER_SET_NAME = 'utf8';

Daca a fost gasit charset-ul atunci putem continua.

Un alt element care apare la charset este collation, acesta se foloseste in comparatii intre string-uri la ordonare.

Pentru a vedea ce “collation” sunt disponibile pe server:

SHOW COLLATION WHERE CHARSET = 'utf8';

sau cu information_schema

SELECT * FROM `COLLATIONS` WHERE CHARACTER_SET_NAME = 'utf8';

Collation este in functie de limba in principiu, pentru a putea compara stringuri cu sau fara diacritice de exemplu, sau se mai poate folosi cel “bin” care va face ordonarea in mod binar, adica “A” este mai mare decat “a” de exemplu.

Daca nu se va specifica collation, atunci se va folosi cel marcat ca default.

UTF-8 si baza de date

La crearea unei baze de date se poate specifica charset-ul default care se va folosi la toate tabelele noi la care nu este specificat charset-ul.

De exemplu:

CREATE DATABASE db_name CHARACTER SET utf8 COLLATE utf8_romanian_ci;

Sau pentru a modifica characterset-ul default la o baza de data deja existenta:

ALTER DATABASE db_name CHARACTER SET utf8 COLLATE utf8_romanian_ci;

UTF-8, tabelele si coloanele

Pentru a modifica tabelele deja existente se foloseste ALTER TABLE.

Un tabel poate avea un charset si un collation default iar fiecare coloana poate avea propriul charset si collation.

Pentru a vedea mai multe detalii despre un tabel se pot folosi:

SHOW CREATE TABLE tab;

Pentru a seta un charset pe un table existent:

ALTER TABLE tab CHARSET = utf8 COLLATE = utf8_romanian_ci;

Pentru a modifica charset-ul pe o coloana de timpul VARCHAR(200) se foloseste:

ALTER TABLE tab MODIFY c1 VARCHAR(200) CHARSET utf8 COLLATE utf8_romanian_ci;

Marimea stringurilor

O “problema” care poate aparea este legata de marimea unui caracter, acesta poate avea marimea intre 1 si 4B. De asta pentru masurarea unui camp care are un string (cum ar fi un varchar) trebuie folosita CHAR_LENGTH(str) si nu LENGTH().

Un mic exemplu:

SET @var = 'aşadar';
SELECT CHAR_LENGTH(@var) AS 'Char', LENGTH(@var) AS 'Length';

// Rezulta: Char = 6 si Length = 7 pentru ca ş ocupa 2B

Written by Claudiu Persoiu

10 August 2009 at 1:40 PM

Posted in MySQL

Tagged with , , ,

MySQL Certified Developer – ultimul episod

without comments

Dupa ce am sustinut examenul MySQL Certified Developer acum cateva saptamani, dupa cum povesteam intr-un blog anterior, a venit si momentul mult asteptat. Este putin indoita ca a fost fortata in cutia postala, dar diploma a venit! Surprinzator a durat doar doua saptamani, fata de cea de la Zend care a durat  aproape 8.

Numele mi-a fost publicat la cateva zile pe site, dar contul nu am putut sa-l accesez decat dupa ce am primit diploma. Ce este mai ciudat este ca inauntru nu scria parola pentru cont, ci instructiunile pentru a o primi.

In afara de diploma, in plic mai exista instructiuni de folosire pentru logo si contului, si pe langa asta un card cu nume si certificare, care nu inteleg la ce o sa-mi foloseasca.

Iar alta ciudatenie este ca, diploma este semnata de Micheal “Monty” Widenius si Marten Mickos care nu mai lucreaza la Sun MySQL. Evident nu stiu cat de adevarate sunt semnaturile, dar macar cea a lui Ulf Sandberg (VP Service MySQL AB) este reala.

Dar diploma arata foarte bine, si face o pereche buna cu cea Zend. Acum sper sa-mi si foloseasca.

Written by Claudiu Persoiu

30 July 2009 at 9:13 PM

Posted in MySQL

Tagged with , ,

Rata de adoptie si dezvoltarea de software pe web

with 2 comments

Cum influenteaza rata de adoptie a noilor produse si/sau versiuni de soft dezvoltarea produselor pentru Web si cele de tip client-server?

Din perspectiva unui web developer, suntem restrictionati de serverele pentru care dezvoltam si browserele clientilor. De multe ori compromisurile merg foarte departe de dragul de a satisface o piata mai larga.

PHP

In prezent versiunea stabila de PHP este 5.3.0, totusi folosirea acestei versiuni in productie ar fi o decizie puierila. Versiunea a aparut de putin timp si probabilitatea de a gasi aceasta versiune pe serverele de hosting este foarte mica.

In mod logic o versiune mai potrivita este 5.2.10. Si totusi, daca versiunea 5 a aparut acum aproape 5 ani, de ce un framework popular precum CakePHP inca nu foloseste avantajele aduse de aceasta versiune? Pentru ca pana de curand o buna parte din serverele de shared hosting care aveau suport pentru PHP, aveau inca versiunea 4.

Cum se traduce asta in productie? Daca nu dezvolti produse interne sau pe servere proprii, sau asupra carora ai control, ar trebui sa fi constient ca produsul tau poate ar trebui sa fie compatibil si cu versiuni de PHP mai vechi, iar noile facilitatie nu trebuiesc folosite.

Trist si ridicol dar adevarat.

PHP 5.3 aduce destul de multe facilitati noi, dar pana aceste facilitati vor putea fi folosite in productie probabil vor mai trece cativa ani. Iar pana acestea vor ajunge si in framework-uri probabil si mai mult (de exemplu namespace-urile sunt utile in framework-uri).

MySQL

Versiunea stabila curenta este 5.1.36.  Versiunea 5.x, lansata in 2005 a adus multe facilitati noi, cateva dintre ele sunt: rutine stocate (functii si proceduri), triggere, views, cursori, information schema etc.

Rutinele stocate probabil reprezinta una dintre cele mai mari schimbari. Acestea sunt cel mai cunoscute probabil de la Oracle PL/SQL, desi MySQL le-a implementat dupa standardul ANSI SQL 2003.

Dar pentru ca MySQL 5.0 a stat mult in beta rata de adoptie este si aici foarte scazuta. Din nou, sunt aproape 4 ani de cand a fost lansata versiunea iar ea inca nu este suficient de raspandita.

Concluzia, pur si simplu nu se recomanda folosirea noilor facilitati daca nu vei putea controla serverul.

Browserele si JavaScript

Problema browserelor ii afecteaza atat pe programatori cat si pe designeri.

Probabil cel mai vechi browser folosit pe o scara inca destul de larga este Internet Explorer 6. Acesta a fost lansat in 2001, adica in urma cu 8 ani si este inca folosit de ~30% dintre utilizatori.

In 2001 JavaScript era considerat inca un limbaj de scripting infantil, care era folosit mai mult pentru efecte vizuale simple.

O data cu “descoperire” AJAX in 2005, JavaScript a prins din nou viata. JavaScript nu mai era doar un limbaj folosit pentru efecte vizuale reduse ci era privit ca o tehnologie de viitor.

Browsere cum ar fi FireFox, Opera, Google Chrome sau Safari au facut progrese mari pentru a imbunatatii viteza de executie pentru JavaScript. Pana si Internet Explorer 8 lucreaza mai bine cu JavaScript, dar este departe de a fi la fel de popular ca versiunea 6. Si ca sa fie completa problema Microsoft are o mare problema cu pastrarea compatibilitatii intre produsele sale.

Motivul pentru aceasta problema de adoptie a noilor versiuni Internet Explorer este de fapt sistemul de operare. Cel mai popular sistem de operare de la Microsoft este Windows XP. Acesta avea preinstalat Internet Explorer 6. Avand in vedere ca Windows Vista a intrat mult mai greu pe piata din pricina bug-urilor initiale, problemelor cu driverele, resurselor consumate si a altor probleme, a insemnat ca Windows XP a ramas inca foarte popular. Evident nu toti care folosesc Windows XP utilizeaza IE 6, multi au facut update sau pur si simplu folosesc alt browser. Dar multi dintre utilizatori folosesc acest browser care vine preinstalat.

Apropo de acest aspect, Windows 7 va fi distribuit in Europa fara IE instalat. Sunt foarte curios cum va influenta asta piata browserelor.

In ultima vreme telefoanele “smart phone” si dispozitivele PDA au devenit tot mai populare. Multa lume le foloseste pentru a naviga pe Internet. Deci dupa problema de compatibilitate cu browserele de pe PC, acum apare si problema de compatibilitate cu browserele de pe mobil. De exemplu, telefonul meu a venit cu doua browsere: Internet Explorer si Opera. Internet Explorer pentru mobil este groaznic, asa ca eu folosesc Opera care face o treaba buna.

Problema este ca multe dispozitive PDA/smart phone cu Windows Mobile au doar Internet Explorer in standard, si  revenim la problema anterioara.

Cand vine vorba de Apple cu renumitul iPhone browserul folosit este Safari (si cred ca nu se poate instala alt browser, dar nu sunt sigur ca mai este inca aceasta problema).

Deci atunci cand realizam o interfata sau o aplicatie JavaScript, ar trebuie sa luam in considerare cateva aspecte cum ar fi:

  • dispozitiv (ex: PC, PDA, smart phone etc.)
  • sistem de operare (ex: Windows, Linux, Mac, Symbian etc.)
  • browser cu versiunea aferenta (Internet Explorer 6,7,8; FireFox, Safari, Opera etc.)
  • HTML 5 este aproape aici, dar cand vine vorba de browsere ma intreb cand se va spune cu adevarat despre HTML 5 ca se poate folosi pe scara larga avand in vedere ca peste jumatate din piata in arest moment este dominata de IE 6 si 7.

    Eu zic ca o sa fie cam 5 ani…

    Written by Claudiu Persoiu

    15 July 2009 at 9:55 PM

    Examen MySQL Certified Developer

    with 12 comments

    Sau mai nou Sun MySQL Certified Developer.

    Ma batea gandul de aproape un an, dar in ultimele luni m-am decis sa fac si pasul asta. Si cum eram usor lipsit de motivatie, pe site-ul MySQL este un anunt ca pe data de 31 Iulie examenulul nu se va mai da in centrele PersonVUE. Asta a fost toata motivatia de care aveam nevoie.  M-am inarmat cu cartea si am pornit la treaba.

    Cartea (MySQL 5.0 Certification Study Guide) nu mai este in totalitate de actualitate, fiind scrisa pentru versinea 5.0 in anul 2005. Totusi trecand peste miciile probleme cu modificarile dintre versiuni, este scrisa foarte bine, foarte explicita si cu multe exemple. Apropo, ce nu scrie in carte nu se cere.

    Cartea are doua parti, prima pentru CMDEV iar a doua pentru CMDBA. Cele doua sectiuni mai fac referire una la alta cand este cazul, dar nu este necesara parcurgerea ambelor sectiuni pentru examen.

    Dupa doua saptamani de studiu din prima parte m-am prezentat la primul examen (CMDEV I). Poate este doar parerea mea, si recunosc, am devenit comod avand in vedere ca in cea mai mare parte lucrez cu MySQL folosind phpMyAdmin, dar examenul imi pare destul de dificil. La Zend cand ai o intrebare cu raspunsuri multiple ai si numarul raspunsurilor care trebuiesc furnizate. La MySQL nu exista nici o regula in sensul asta, intradevar pot fi unul sau mai multe raspunsuri corecte.

    Un alt element de noutate, cel putin pentru mine, la final am primit si scorul, si chiar daca nu a fost aproape de limita… tot mi se pare un pic dezamagitor.

    Dupa primul examen, nu am stat mult sa sarbatoresc ca am inceput sa ma pregatesc de partea a doua.

    Unii spun ca examenul nu este bine echilibrat, iar eu cred ca au dreptate. In al doilea examen pentru certificare sunt multe elemente de care eu unul doar am auzit, sau le-am folosit cu Oracle. Motivul pentru care nu am apucat sa le folosesc pana acum este simplu: multe servere inca NU au MySQL 5.x! O alta problema este aceea ca phpMyAdmin nu avea nici un fel de suport pentru rutine stocate, triggere etc. Dar din fericire din fericire in MySQL 5.x exista Information Schema, dar desprea asta poate in alt post.

    Al doilea examen mie unul mi s-a parut ceva mai intortochiat. Daca primul l-am rezolvat intr-o ora, pe al doilea l-am rezolvat in aproape o ora jumatate (cat timpul alocat). Exemplele sunt destul de mari si trebuie interpretate cu atentie.

    Dar intr-un final am reusit!

    Din pacate treaba nu merge la fel de usor ca la Zend, acolo pana am ajuns acasa de la examen am primit si siglele (pe e-mail), termenii si conditiile de folosirea a siglelor si am putut sa-mi public profilul pe site.

    La MySQL trebuie sa primesc o hartie prin posta (ne electronica) care ar trebui sa ajunga in 4-6 saptamani. Pana atunci nu-mi ramane decat sa astept…

    Written by Claudiu Persoiu

    8 July 2009 at 11:57 PM

    Posted in MySQL

    Tagged with , , ,

    Fisiere stocate in baza de date cu PHP si MySQL

    without comments

    In continuare voi prezenta un mic tutorial despre stocarea fisierelor in baza de date.

    Cand avem nevoie de stocarea fisierelor in baza de date? Un scenariu bun este atunci cand fisierele sunt confidentiale.

    Dezavantajul principal este viteza de acces, cat timp mai este si o baza de date la mijloc asta va intarzia procesul de regasire/afisare.

    Structura bazei de date:

    CREATE TABLE IF NOT EXISTS fisiere (
      ID int(10) unsigned NOT NULL AUTO_INCREMENT,
      nume varchar(255) NOT NULL,
      tip varchar(255) NOT NULL,
      marime int(11) NOT NULL,
      fisiere longblob NOT NULL,
      timp int(11) DEFAULT NULL,
      PRIMARY KEY (`ID`)
    ) ENGINE=MyISAM

    Trebuie sa stocam tipul, marimea si continutul fisierului propriuzis. Numele este retinut mai mult pt extensie.

    Conectarea la baza de date:

    <?php
    // db.php
    mysql_connect('localhost', 'user', 'parola');
    mysql_select_db('fisiere');
    
    // am omis intentionat tag-ul de inchis pt PHP
    // ca sa am certitudinea ca nu se trimit headere

    Fisierul de upload si listare:

    In acest fisier se afla adaugare, stergerea si listarea fisierelor din baza de date

    <?php
    // legatura la baza de date
    include('db.php');
    
    // mesaj de eroare
    $errmsg = NULL;
    
    // stergerea fisierului din BD
    if(isset($_GET['del']))
    {
        $qr="DELETE FROM fisiere WHERE ID='".mysql_escape_string($_GET['del'])."'";
        if(!mysql_query($qr)) {
           $errmsg = 'Fisierul nu a putut fi sters!<br>';
        }
    }
    
    // verificam daca a fost trimis un fisier si are diminesiunea mai mare de 0
    if($_FILES['fisier']['size'] > 0) {
    
       // se citeste continutul fisierului
       $content = file_get_contents($_FILES['fisier']['tmp_name']);
    
       // se codeaza cu base64_encode pt a nu aparea probleme la caractere speciale
       //si se sparge in bucati
       $content = chunk_split(base64_encode($content));
    
       // se introduc datele in baza de date
       $qr="INSERT INTO fisiere SET
          nume   ='".mysql_escape_string($_FILES['fisier']['name'])."',
          tip    ='".mysql_escape_string($_FILES['fisier']['type'])."',
          marime ='".mysql_escape_string($_FILES['fisier']['size'])."',
          fisiere='".$content."',
          timp   ='".time()."'";
    
       // se verifica daca datele au fost inserate cu succes
       if(mysql_query($qr)) {
          // daca datele au fost stocare cu succes se face refres la pagina
          // pentru a evita cazul in care utilizatorul apasa "refresh"
          header("Location: ".$PHP_SELF."?ok=1");
          exit();
       } else {
          $errmsg = 'Eroare la upload<br>';
       }
    
    }
    ?>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <title>Fisiere</title>
    </head>
    
    <body>
    <?php
    if($_GET['ok']==1) echo "fisierul a fost incarcat!";
    // afisaza mesajul de eroare daca acesta exista
    if($errmsg) echo $errmsg;
    ?>
    
    <?php
    // selecteaza fisierele din BD
    $qr="SELECT * FROM fisiere ORDER BY timp";
    $rez=mysql_query($qr);
    if(mysql_num_rows($rez)>0) {
    ?>
    <table border="1">
       <tr>
          <td>ID</td>
          <td>Nume</td>
          <td>Ora</td>
          <td>Descarca</td>
          <td>sterge</td>
       </tr>
       <?php
       while($row=mysql_fetch_array($rez)) {
       ?>
       <tr>
          <td><?php echo $row["ID"]; ?></td>
          <td><?php echo $row["nume"]; ?></td>
          <td><?php echo date("d-m-Y",$row["timp"]); ?></td>
          <td><a href="descarca.php?ID=<?php echo $row["ID"]; ?>">descarca fisier</a></td>
          <td>
            <a href="<?php echo $_SERVER['PHP_SELF']; ?>?del=<?php echo $row["ID"] ?>"
                onclick="return confirm('doriti sa stergeti acest fisier?');">
              sterge
            </a>
          </td>
        </tr>
        <?php } ?>
    </table>
    <?php
    } else {
        echo "nu exista fisiere in baza de date!";
    }
    ?>
    <br />
    <br />
    <form method="post" enctype="multipart/form-data"
       action="<?php echo $_SERVER['PHP_SELF']; ?>">
    <input type="file" name="fisier" />
    <input type="submit" value="Incarca" />
    </form>
    </body>
    </html>

    Descarcarea fisierului:

    <?php
    include('db.php');
    
    // selectarea fisierului din BD
    $qr="SELECT * FROM fisiere WHERE ID='".mysql_escape_string($_GET['ID'])."'";
    $rez=mysql_query($qr);
    $row=mysql_fetch_array($rez);
    
    $size = $row['marime'];
    $type = $row['tip'];
    $name = $row['nume'];
    $fisiere = $row['fisiere'];
    
    // dezactivam compresia pt ca nu aparea erori la afisare
    if(ini_get('zlib.output_compression'))
    ini_set('zlib.output_compression', 'Off');
    
    // fisierul trebuie descarcat de pe server nu din cache
    header("Pragma: public");
    header("Expires: 0");
    header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
    header("Cache-Control: private",false); 
    
    // dimensiunea fisierului
    header("Content-length: ".$size);
    
    // tipul fisierului
    header("Content-Type: ".$type); 
    
    // optional daca dorim sa forteze download-ul
    header("Content-Type: application/force-download");
    
    // numele fisierului cu care va fi salvat pe disk
    header("Content-Disposition: attachment; filename=\"".$name."\";"); 
    
    // transfer binar pt a evita caracterele speciale
    header("Content-Transfer-Encoding: binary");
    
    // decodam continutul fisierului si il afisam
    echo base64_decode($fisiere);
    
    ?>

    Dupa cum se poate vedea serverul are destul de multe lucruri de facut pentru a afisa un simplu fisier, de asta nu este bine sa fie stocate pe disk toate fisierele, ar fi o risipa de resurse. Pe de alta parte,  fisierele private (cum ar fi cartile digitale sau melodiile) sunt clienti ideali pentru aceasta forma de stocare.

    Written by Claudiu Persoiu

    18 May 2009 at 4:00 PM

    Posted in MySQL,PHP

    Tagged with , , ,

    E mai sigur sa fi “dummy” cand vine vorba de MySQL – folositi –i-am-a-dummy

    without comments

    Da, nu e o gluma, chiar exista acest parametru, iar el este sinonim cu –safe-updates.

    Cum ii spui clientului mysql ca esti dummy?

    shell>mysql --i-am-a-dummy

    Iar pentru sinceritate, clientul mysql nu o sa te lase sa:

    • stergi sau sa modifici (DELETE, UPDATE) daca nu ai conditii puse
    • afisezi mai mult de 1000 de randuri de inregistrari
    • selecturi multiple care necesita procesarea a mai mult de 1 milion de randuri

    Uneori este mai sigur sa recunosti ca poti fi putin dummy decat sa o dovedesti…

    Written by Claudiu Persoiu

    11 May 2009 at 10:40 PM

    Posted in MySQL

    Tagged with

    MySQL intra sub umbrela Oracle

    without comments

    Da, MySQL va intra sub umbrela Oracle odata cu achizitionarea sa de catre aceasta corporatie.

    Achizitionarea nu este directa ci prin intermediul Sun (JAVA) care la randul lor au cumparat MySQL cu ceva timp in urma.

    Incepand de pe 20 aprilie 2009 e oficial, Oracle va achizitiona Sun si deci MySQL, asa cum a fost anuntat pe site-ul Sun.

    Sunt foarte curios care o sa fie rezultatul, in special ca cele doua SGBD-uri sunt populare in sectoare de piata diferite. Probabil MySQL ar putea profita de experienta Oracle, oricum probabil Oracle nu era interesat atat de interesat de tranzactia cu MySQL cat de tranzactia cu Sun.

    Daca ne gandim practic Oracle mananca “cu pofta” toate resursele care le are disponibile, pe cand MySQL este cunoscut pentru consumul redus de resurse. O sa fie foarte ciudat ca aceste opusuri sa faca parte dintr-o singura corporatie.

    Oricum, rezultatul este ca Oracle va controla majoritatea pietei de SGBD-uri prin cele doua produse de acest gen care le va dezvolta.

    Written by Claudiu Persoiu

    23 April 2009 at 9:49 PM

    Posted in Diverse,MySQL

    Tagged with , ,