fonte: dal web
Quando dobbiamo lavorare con una mole di dati interessante diventa difficile gestire operazioni che normalmente non creano problemi, come ad esempio l’import e l’export di dati da un database.
Di fronte ad esempio ad un file .sql contenente 20mila record, anche modifcando le direttive post_max_size e upload_max_filesize, diventa difficile poter utilizzare le interfacce grafiche, come ad esempio phpMyAdmin, perchè si bloccano o “crashano”.
Zend Framework è uno tra i principali framework (se non il principale) per lo sviluppo di applicazioni enterprise in PHP. E’ uno strumento molto potente al servizio degli sviluppatori PHP: è estremamente flessibile, estendibile, facile da usare e decisamente manutenibile. Questo è il primo di una serie di articoli che sto preparando per presentare quelle che sono le caratteristiche più interessanti di questo prodotto.
L’argomento che trattiamo in questo articolo è la gestione delle transazioni con Zend Framework. Una transazione è una sequenza di operazioni che deve rispettare le proprietà ACID ( Atomicity, Consistency, Isolation, e Durability – Atomicità, Coerenza, Isolamento e Durabilità). Una transazione può terminare con successo o con un insuccesso: nel primo caso il risultato sarà permamente, mentre nel caso di insuccesso di deve tornare alla situazione precedente l’inizio della transazione, come se nulla fosse successo.
Qualche giorno fa abbiamo avuto la conferma: Oracle non solo non abbandonerà il progetto MySQL, ma anzi, ha rilanciato con la promessa di importanti investimenti e soprattutto novità tecniche per nulla trascurabili.
Con la nuova versione (la 5.5), MySQL diventerà più performante del 200% e i tempi di ripristino saranno ridotti di 10 volte….insomma una vera rivoluzione: ma il piatto forte sarà la maggiore integrazione con il motore di archiviazione InnoDB, che diventerà quello di default.
Insomma, quello che forse è il più diffuso e il più utilizzato RDBMS open source conoscerà nuova vita: non ci resta che provare per credere! 
Per chi volesse notizie più complete circa le novità introdotte con la nuova versione di MySQL può trovarle in questo articolo.
La password di root per il server MySQL è un dato da considerarsi estremamente sensibile, vista l’importanza che ricopre. Diventa di vitale importanza tenere sempre a portata di mano una procedura che ci permetta di recuperare questo dato in caso di necessità.
E’ possibile recuperare la password di root eseguendo questi 5 passi:
Step # 1: Fermare il processo server MySQL
Step # 2: “Startare” il processo server MySQL con l’opzione –skip-grant-tables
Step # 3: Connettersi al server MySQL come utente root
Step # 4: Configuriamo la nuova password per l’account di root
Step # 5: Usiamo e “restartiamo” il server MySQL.
Per ogni step, di seguito è possibile visionarne i commandi (da eseguire loggati come utente root):
Step # 1 : Fermare il server MySQL
# /etc/init.d/mysql stop
Output:
Stopping MySQL database server: mysqld.
Step # 2: Avviare il server MySQL senza password:
# mysqld_safe --skip-grant-tables &
Output:
[1] 5988
Starting mysqld daemon with databases from /var/lib/mysql
mysqld_safe[6025]: started
Step # 3: Connessione al server MySQL usando il client MySQL:
# mysql -u root
Output:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.1.15-Debian_1-log
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.
mysql>
Step # 4: Settiamo la nuova password per l’utenza root del server MySQL
mysql> use mysql;
mysql> update user set password=PASSWORD("NEW-ROOT-PASSWORD") where User='root';
mysql> flush privileges;
mysql> quit
Step # 5: Stoppiamo il server MySQL:
# /etc/init.d/mysql stop
Output:
Stopping MySQL database server: mysqld
STOPPING server from pid file /var/run/mysqld/mysqld.pid
mysqld_safe[6186]: ended
[1]+ Done mysqld_safe –skip-grant-tables
Step # 6: Avviamo il server MySQL ed effettuiamo il primo accesso
# /etc/init.d/mysql start
# mysql -u root -p
I programmatori si trovano molto spesso a lavorare con le date: in applicativi di gestione del contenuto ad esempio, sono praticamente un elemento obbligatorio senza il quale molte operazioni basilari, come gli ordinamenti cronologici, non sarebbero possibili.
Ecco perchè diventa molto importante saper gestire questo tipo di dato. Vi sono molti modi differenti di manipolare le date, ma quello che vogliamo presentare oggi è una soluzione che riguarda il salvataggio di date in una base di dati e il conseguente recupero.
Molti programmatori utilizzano le funzioni di manipolazione delle stringhe per formattare le date, ignorando che tale soluzione è poco performante ed ancora meno efficiente. Quando si lavora ad un progetto con un database alle spalle, bisogna sempre tenere presente che far eseguire alcuni tipi di operazioni al DBMS piuttosto che all’interpreste del linguaggio di programmazione (nel caso del PHP, ad esempio) è sicuramente molto più performante oltre che leggibile.
Bisogna a questo scopo conoscere alcune funzionalità che i database, o meglio, i DBMS, mettono a disposizione. Una di queste è proprio DATE_format , che appunto durante una interrogazione permette di inserire nel result set le date già formattate e pronte per l’utilizzo.
Vediamo un esempio:
SELECT title, created DATE_format(created, ‘ %e/%m/%Y, %l:%i%p’) as created
FROM table
WHERE category=1
ORDER BY created DESC
Supponiamo di avere una tabella per le notizie, da cui vogliamo recuperare il titolo e appunto la data di crezione di ogni item.
Attraverso l’utilizzo della funzione DATE_format messa a disposizione dal motore di MySQL, riceviamo una data già formatta è pronta per l’uso, senza dover richiamare ulteriori funzioni di formattazione o di manipolazione di stringhe, con un conseguente aumento delle prestazioni (seppure di pochi microsecondi nella maggior parte dei casi) e della leggibilità del codice.
DATE_format accetta due parametri: il primo è la data da formattare, il secondo è una stringa di formattazione, che segue delle regole simili a quelle utilizzate per questo tipo di stringhe dalla maggior parte dei linguaggi di programmazione, e che trovate qui.
A questo punto, quando si utilizzerà il relativo result set, si potranno usare direttamente sia il campo title che il campo created senza ulteriosi interventi da parte del programmatore.
