+ Rispondi al Thread
Visualizzazione dei risultati da 1 a 1 su 1

Discussione: PHP 5: Scegliere un database - parte 3°

  1. #1
    L'avatar di McGraw-Hill
    McGraw-Hill non è in linea Novello
    Post
    6
    Funzioni avanzate

    Questo paragrafo descrive le funzioni di database SQL specifiche con le quali si può non avere ancora familiarità. Si spera che sia possibile comprendere, anche da una descrizione così veloce, se si ha veramente bisogno di una o più di queste funzioni.

    GUI

    I database variano enormemente dal punto di vista degli strumenti di interfaccia utente. Le scelte spaziano dalle più rigide interazioni a riga di comando ai massicci kit di strumenti di sviluppo forniti da Java. Si paga per ciò che si desidera, sia in contanti che in prestazioni. Cercare l’interfaccia più chiara che soddisfi le proprie esigenze, poiché una GUI può aumentare enormemente i costi. Un’alternativa a basso costo alla GUI incorporata è un’interfaccia Web.
    Queste spesso vengono personalizzate, ma ci sono anche prodotti di terze parti che possono soddisfare le proprie esigenze. Per esempio, MySQL possiede diverse interfacce basate sul Web disponibili gratuitamente, che si possono trovare in Freshmeat (www.freshmeat.net) o SourceForge (http://sf.net). La più famosa è probabilmente PHPMyAdmin, disponibile sul sito Web di PHPMyAdmin (www.phpmyadmin.org).

    Subquery

    Una subquery o sotto selezione è una dichiarazione SELECT inclusa, come questa:

    codice:
    SELECT * FROM table1 WHERE id IN (SELECT id FROM table2);
    Esistono modi per raggirare la mancanza di sotto selezioni, e non tutti ne hanno bisogno. Tuttavia, possono far risparmiare un po’ di tempo se la necessità di eseguire grandi selezioni, inserimenti e cancellazioni è alta.

    SELECT INTO

    SELECT INTO è una comoda funzione se si desidera spostare frequentemente i dati da una tabella all’altra. La sintassi può variare leggermente. Un metodo è:

    codice:
    SELECT INTO table2(col2, col3, col7) lastname, firstname, state FROM table1 WHERE col5 = NULL;
    Un altro modo per ottenere lo stesso risultato è:

    codice:
    INSERT INTO table2(col2, col3, col7) SELECT lastname, firstname, state FROM table1 WHERE col5 = NULL;
    Unioni complesse

    Un’unione è un modo di cercare qualcosa attraverso le tabelle utilizzando valori condivisi per accoppiare le tabelle. La forma più semplice è:

    codice:
    SELECT * FROM table1,table2 WHERE table1.id=table2.id;
    Questo produce i contenuti completi di qualsiasi riga nelle due tabelle che condividono i numeri di ID. Esistono altri tipi di unioni più specifici ed estesi, compresi sinistra o destra, diritto o incrociato, interno ed esterno, ma sono poco utilizzati. Le unioni sono molto pratiche e fanno risparmiare tempo, a volte sono quasi essenziali, ma in pratica pochi hanno veramente bisogno di modelli più esoterici. Quindi, non si deve rifiutare un database incontrollabile perché manca la giusta unione esterna.

    Thread e blocchi

    I thread e i blocchi sono molto importanti per siti multi tier e a due tier con molti collaboratori. Impediscono che due chiamate al database si scontrino una con l’altra, fornendo il controllo editoriale solo a una singola transazione alla volta.
    Un esempio che spiega chiaramente il valore dei thread e dei blocchi è un sito Web che vende biglietti per concerti rock. Ovviamente, non si desidera che due persone acquistino lo stesso posto per la stessa manifestazione a causa di un errore del database. Il database ha bisogno di alcuni modi per riconoscere le richieste uniche e permettere che solo un utente (o thread) esegua le modifiche in un qualsiasi momento stabilito, mentre gli altri vengono bloccati finché non è stata completata la prima transazione. A meno che non si sia sicuri che il progetto (per esempio, un Web log) avrà un solo utente alla volta, si faccia attenzione nell’affidarsi a un database senza thread.

    Database transazionali

    Questo termine si riferisce a un progetto di database che cerca di massimizzare l’integrità dei dati. Il paradigma transazionale conta su assegnazioni e rollback. Le transazioni concluse con successo verranno assegnate al database. Quelle che non hanno avuto successo non verranno salvate, o il database verrà riportato alla sua condizione precedente.
    In generale, le transazioni diventano più utili in situazioni in cui si desidera venga assegnato tutto o niente a un gruppo di inserimenti. Un sistema di e-commerce può utilizzare i rollback in situazioni dove viene rifiutata la carta di credito di un cliente, scegliendo di non registrare le informazioni sul cliente, l’ordine d’acquisto, la modifica dell’inventario e così via. I rollback sono anche utili in caso di alterazione dei dati, come quando un server di database subisce un blocco hardware.
    Un progetto alternativo di integrità dei dati viene chiamato atomico. I sostenitori del paradigma atomico dichiarano che è molto più veloce e ugualmente sicuro, ma le transazioni possono risultare più semplici per numerosi programmatori, poiché c’è più logica a livello del database.

    Procedure e trigger

    Le procedure sono query o routine memorizzate e precompilate sul server di database. Una comune procedura è quella che seleziona tutti gli indirizzi di posta elettronica dei clienti che hanno fatto acquisti un particolare giorno.
    Se si utilizzano le stesse dichiarazioni di selezione più volte, le procedure possono raccoglierle in modo pratico e veloce. I trigger sono procedure che si verificano quando alcuni eventi vengono registrati dal database. A seconda del database, si può scrivere un trigger per inviare un messaggio di posta elettronica con l’estratto conto ai clienti o ai soci del sito, e impostarlo perché il messaggio venga spedito ogni domenica a mezzanotte. Un altro utilizzo pratico consiste nello spedire un messaggio di posta elettronica all’amministratore del database ogni volta che viene registrato un errore. Relativamente pochi database utilizzano i trigger, poiché sfruttano una grande quantità di energia programmatica e molti cicli supplementari per rintracciare i possibili eventi.

    Indici

    Gli indici rappresentano un modo per velocizzare le ricerche di grandi set di dati. Si supponga di dover trovare il particolare file di un cliente in una vasta pila di file gettati a caso sulla propria scrivania. Oppure si potrebbe cercare il file in un gruppo di raccoglitori sistemati in ordine alfabetico. Ovviamente, il sistema dei file in raccoglitori sarà più veloce, perché manterrà i documenti preordinati in piccole cartellette. In una nutshell questo è ciò che fa un indice.
    Se si hanno milioni di utenti sarà estremamente lento per un database trovarne uno in base al cognome, perché il programma dovrà esaminare ciascuna voce presente nel campo del cognome e confrontarla con la stringa che si sta cercando. Un indice posizionato su quella colonna permetterà al database di eseguire la ricerca solo in una parte del set di dati, e questo renderà la ricerca più veloce.
    Tuttavia, gli indici non devono essere usati da chiunque. Innanzitutto, rallentano la scrittura e accelerano la lettura. Non necessariamente accelerano ogni tipo di query, e il set di dati potrebbe non essere grande abbastanza per mostrare una differenza di velocità apprezzabile. Gli indici aiuteranno molto se si possiede un bilione di voci, ma potrebbero non aiutare affatto se le voci sono solo 500.

    Chiavi esterne e limitazioni di integrità

    La struttura relazionale di un database è spesso implicita nei modi in cui i campi di una tabella si riferiscono agli ID di riga di un’altra, ma il database non farà necessariamente niente di utile per assicurare che la struttura venga rispettata quando si eseguono le modifiche. Un modo in cui il database può essere utile è attraverso le cancellazioni a cascata: cancellando automaticamente
    le righe che dipendono da altre righe che sono state eliminate (questo a volte è implementato come trigger). Per esempio, se si cancella il record di un paziente dell’ospedale, si può desiderare che anche tutte le righe orfane nella tabella corrispondente alle sue visite vengano automaticamente eliminate. In alternativa, un sistema di database può semplicemente impedire la cancellazione delle righe genitore a meno che prima non vengano cancellate le potenziali orfane. Se questo tipo di limitazione è un salvavita o semplicemente una noiosa restrizione dipende da quanto è importante che la struttura relazionale sia del tutto affidabile e coerente, e quanto frequente sia il bisogno di questo tipo di operazioni pericolose. La maggior parte di queste funzioni può essere implementata, sebbene in modo meno chiaro ed efficace, con una combinazione di chiavi tradizionali e il codice client che si utilizza per manipolare i dati.

    Replica del database

    Quando i dati memorizzati aumentano, è necessario pensare al potenziamento. Per un determinato periodo, è semplicemente possibile spostare il server di database su macchine più veloci con più processori e dischi più capienti, ma prima o poi un database in crescita dovrà essere replicato su più di un server.
    Per eseguire questa operazione sono necessari alcuni mezzi che tengono automaticamente sincronizzati i diversi server. Questo normalmente comprende un sistema di registrazione, e spesso una relazione master-slave tra i server di database. Un database è il master, e in esso vengono inseriti tutti i nuovi dati. Un registro tiene traccia di queste modifiche in ordine cronologico.
    Tutti gli altri server sono slave, che mettono a disposizione i dati invece di conservarli. Leggono periodicamente il registro master ed eseguono le stesse modifiche al loro interno.
    Il passo successivo è un tipo di meccanismo failover, per il quale uno slave può diventare il server di database master se il master si blocca. Si pensi attentamente al livello di sicurezza che devono avere i dati, poiché è molto costoso.
    Ultima modifica di Master85; 20-11-2006 16:03 
    McGraw-Hill Informatica
    Visita il nostro catalogo online http://www.informatica.mcgraw-hill.it

+ Rispondi al Thread

Discussioni simili

  1. Articolo: PHP 5: Scegliere un database - parte 4°
    Da McGraw-Hill nel forum PHP
    Risposte: 0
    Ultimo Post: 21-12-2005, 10:25
  2. Articolo: PHP 5: Scegliere un database - parte 2°
    Da McGraw-Hill nel forum PHP
    Risposte: 0
    Ultimo Post: 19-12-2005, 23:28
  3. Articolo: PHP 5: Scegliere un database - parte 1°
    Da McGraw-Hill nel forum PHP
    Risposte: 0
    Ultimo Post: 15-12-2005, 15:35

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi