PHP 5: Scegliere un database - parte 1°

[McGraw-Hill]

Introduzione

I database e PHP si sposano come torta e gelato, Trinidad e Tobago, uova fresche e prosciutto, tanto per rendere l’idea. Dopo tutto, cos’è il Web? La creazione di vasti archivi di informazione disponibili a un pubblico più o meno vasto. Non che non ci sia abbondanza di piccoli siti brochureware; ma più è grande e più spesso viene aggiornata la sorgente dei dati, più il valore comparativo viene fornito dal Web rispetto agli altri mezzi di comunicazione.
Forse il vantaggio maggiore di PHP rispetto a prodotti simili è la scelta insuperata e la facilità di connessione ai database che offre. Come descritto nel paragrafo “Scegliere un database” di questo capitolo, PHP supporta connessioni native ai database più popolari, open source e prodotti commerciali simili. Alla fine è possibile includere quasi tutti i database che apriranno la loro API al pubblico. Per qualsiasi database non supportato, c’è il supporto ODBC generico.

Cos’è un database?

Un database è un’applicazione separata che memorizza una raccolta di dati. Ciascun database possiede una o più API distinte per creare, accedere, gestire, cercare, e replicare i dati che contiene. È possibile utilizzare altri tipi di
memorizzazione dei dati, come i file nel filesystem o ampie tabelle hash in memoria, ma quando si parla di database si intende un’applicazione autonoma come Oracle o SQL Server o Sleepycat.

Perché un database?

Se si decide di utilizzare PHP, probabilmente presto o tardi servirà un database. Anche per qualcosa di piccolo, come un Weblog personale, occorre pensare seriamente ai vantaggi che offre l’utilizzo di un database invece delle pagine statiche o dei file di testo inclusi.

Mantenimento e scalabilità

Avere PHP che assembla le pagine in tempo reale da un modello e un database è un’esperienza unica. Una volta provata, non si tornerà mai più a gestire un sito HTML statico di qualsiasi dimensione. Con lo sforzo di programmazione di una pagina, si possono produrre un numero infinito di pagine uniformi. Se ne cambia una e tutte le altre vengono modificate di conseguenza.
Oggi esistono siti Web con centinaia di migliaia di pagine separate (sicuramente non c’è nessuno che le gestisce tutte a mano). Se si possiede un concetto Web che potrebbe svilupparsi in più di alcune dozzine di pagine, si dovrebbe pensare di passare all’utilizzo dei database il più presto possibile.

Portabilità

Poiché un database è un’applicazione e non una parte del sistema operativo, è possibile trasferire facilmente la sua struttura e i contenuti da una macchina a un’altra, o (in certi casi) anche da una piattaforma a un’altra. Questo è particolarmente importante per gli imprenditori, che possono sviluppare un progetto senza possibilità di controllo dell’ambiente nel quale verrà inserito: possono consegnare un pacchetto di PHP più lo schema del database MySQL copiato in un tarball o file zip. Esistono anche programmi PHP molto conosciuti, come vBulletin, che mantengono buona parte del codice in un database per renderlo più facilmente distribuibile.

Evitare programmazioni difficili

Certe cose che si possono eseguire con PHP non andrebbero fatte, perché implicano mosse di programmazione sgradevoli o rischiose. Si supponga di essere il comandante della nave spaziale Enterprise e di mantenere il diario del Capitano. Ogni episodio è contenuto in un file di testo identificato da una data spaziale unica, inserito da PHP in un modello; il comandante è un uomo dello spazio molto impegnato con intere galassie da esplorare; non c’è il tempo di scrivere il diario ogni giorno. Si desidera inserire su ogni pagina i collegamenti Avanti e Indietro generati automaticamente per chi vuole leggere il diario in ordine cronologico. È abbastanza facile utilizzare PHP per trovare l’inserimento precedente, ma qualsiasi sforzo per localizzare quello successivo può diventare velocemente un ciclo infinito, perché è più facile provare qualcosa che esiste rispetto a qualcosa che non esiste. Per contro, se si inseriscono i dati di log in un database, l’intero lavoro diventerà banale.
Il database indicherà qual è l’ultimo inserimento in ogni dato momento. Esistono altri tipi di lavori di programmazione che un database è altamente ottimizzato a compiere, e dandogliene l’occasione è poi possibile sfruttarli. Per esempio, non si devono mai ordinare i dati impostati sul lato PHP, ma occorre imparare a scrivere le proprie query in modo che ritornino preordinate. Questi problemi di efficienza saranno descritti più dettagliatamente nel Capitolo 18.

Ricerca

Sebbene per le stringhe sia possibile cercare file di testo multipli (specialmente sulle piattaforme UNIX), non è quello che molti sviluppatori Web vorrebbero fare spesso. Dopo la ricerca su un centinaio di file, il compito diventa lento e difficile da gestire. I database esistono per facilitare le ricerche. Con un unico comando si può trovare qualsiasi cosa, da un numero di identificazione, a un ampio blocco di testo, a un’immagine in formato JPEG.
In alcuni casi, l’informazione ha valore solo quando viene inserita in un database di ricerca. Per esempio, poche persone vorrebbero leggere un lungo elenco di testo riguardante i registi e i loro film; ma occasionalmente molte
desiderano eseguire una ricerca in un database a caccia di tali informazioni. Qui si può obiettare che è la ricerca, tanto quanto l’informazione stessa, che crea il valore.

Sicurezza

Un database, se utilizzato con la sue password, offre un ulteriore livello di sicurezza. Si supponga di utilizzare PHP per gestire i file dei clienti di una società, contenenti informazioni sui prezzi pagati da ciascun cliente per i prodotti e i reclami eseguiti. Queste informazioni sarebbero oro per la concorrenza e sarebbe imbarazzante se fossero disponibili a tutti; ma devono essere inserite in Internet così da essere accessibili al proprio esercito di venditori. Se PHP scrive ogni nuovo record del cliente in un file di testo, occorre fornire all’utente del server HTTP l’accesso in scrittura alla directory più sensibile (di solito nessuno o tutti). Non è una buona idea. Facendo invece in modo che PHP scriva in un database, si possono mantenere i permessi di accesso alle directory in sola lettura, e anche richiedere una seconda password prima che il database possa essere modificato.
Oppure si consideri il caso di un sito di contenuto con un vasto numero di visitatori, un numero più ridotto di scrittori e una manciata di editori. Si possono impostare facilmente i livelli di permesso di accesso al database

per ogni gruppo, in modo che i visitatori possano solo leggere il contenuto del database (formattato nelle pagine Web), gli scrittori possano sfogliare e modificare solo i loro inserimenti, e gli editori possono fogliare/modificare/ cancellare qualsiasi cosa nel sito.

Architettura multilivello

Finora sono stati considerati solo i siti cosiddetti a due tier: PHP prende dati puri da alcuni tipi di sistemi di memorizzazione e li trasforma in HTML. Tuttavia, uno dei propositi di PHP è diventare il “collante” nello sviluppo a tre o più tier. Se si possiede qualcosa di più complesso della semplice architettura a due tier, allora si ha veramente bisogno di un database. Un’architettura a diversi tier è un numero arbitrario di sotto sistemi di
software collegati da un sito Web sul front end e uno o più database sul backend. Un’architettura a diversi tier abbastanza comune è quella di un grande sito di e-commerce, con carrelli della spesa collegati a sistemi di ricevimento ordini collegati a procedure di gestione delle catene di rifornimento, più database dei prodotti e dei clienti, addebiti delle carte di credito, FAQ, motori di consigli, strumenti di analisi delle registrazioni Web, memorizzazione di proxy e chissà cos’altro si nasconde dietro le quinte. In queste condizioni, è necessario disporre di caratteristiche avanzate di database, come descritto nel paragrafo “Funzioni avanzate” di questo capitolo.

Il potenziale rovescio della medaglia: le prestazioni

Si potrebbe essere preoccupati delle prestazioni. È vero che un sito basato su un database sullo stesso hardware e software sarà sempre più lento di un sito statico. È vero che certi database sono più veloci di altri. Tuttavia, la
questione reale è se i margini di prestazione possano essere mai rilevati. Se si sta parlando di aggiungere millesimi di secondi alla propria latenza, a chi importa? Alcune delle preoccupazioni riguardanti le prestazioni che si leggono su Internet sono così gonfiate che rasentano l’assurdo. Una volta che si necessita di entrare nel database anche per una sola parte di informazione per pagina, è quasi sempre vantaggioso inserire tutti i dati
nel database. La maggioranza delle informazioni addizionali di una query al database viene caricata anticipatamente quando si stabilisce una connessione. Se si dovesse eseguire questa operazione per ottenere un nome o un titolo, il download di qualche migliaio di parole di testo è praticamente gratuito. In conclusione, solamente i test delle prestazioni potranno stabilire se un database è troppo lento per le proprie impostazioni e operazioni, tutto il resto sono solo chiacchiere. Molti siti Web completamente basati su database ottengono facilmente sotto secondi di latenza, che dovrebbero essere sufficienti per la maggioranza degli scopi.