Sei in: Per i Webmaster - Tutorials - Colleghiamoci a tutti i database
Un problema di prestazioni
Diversamente da come molti pensano, per la connessione a database in ASP non esiste solo ODBC. Certamente è il metodo più usato e forse il più semplice da implementare abbinandolo ai DSN, ma non è l'unico e neanche il più veloce. Come avrete già capito dal titolo dell'articolo l'alternativa di cui sto parlando si chiama OLE-DB. Come sapete l'ambiente ASP non è altro che un insieme di oggetti e componenti richiamati con un linguaggio di scripting (Vbscript, Jsscript o altri). Uno di questi componenti è ADO (Activex Data Object) che si occupa appunto della comunicazione con le sorgenti di dati (database), e OLE-DB è appunto una parte di esso. Per capire meglio come lavora OLE-DB all'interno di ADO bisogna aprire una parentesi sui concetti di Data Consumer e Data Provider.
Data Consumer
Il Data Consumer è una qualunque applicazione che richiede dei dati per una successiva elaborazione all'interno del proprio codice. Nel nostro caso il Data Consumer è la pagina ASP in quanto si occupa della richiesta dei dati al database per elaborarli successivamente.
Data Provider
In contrapposizione, il Data Provider, è colui che si occupa del dialogo diretto con il DB per l'estrapolazione dei dati richiesti e che successivamente li passerà al Data Consumer. Nel nostro caso il Data Provider è OLE-DB. Esattamente come succede per l'ODBC (che è esso stesso un Data Provider) ogni database ha bisogno di un suo OLE-DB specifico che ne conosca la struttura e che sappia come prendere i dati. In pratica sia OLE-DB che ODBC sono due Data Provider e superficialmente si potrebbe pensare ad una equivalenza tra i due ma vedremo che non è così.
Perché usare OLE-DB al posto di ODBC.
Forse qualcuno ci rimarrà male dal non vedere ancora neanche una linea di codice, ma ciò deriva dal fatto che le modifiche per utilizzare OLE-DB sono veramente esigue mentre la filosofia che si basa dietro ai due mondi è completamente diversa ed è questa che bisogna capire per apprezzare le differenze tra i due metodi. OLE-DB è uno dei primi passi che la Microsoft ha fatto per implementare efficacemente la sua strategia chiamata UDA (Universal Data Access). Lo scopo di UDA è di rendere accessibili, in modo uniforme, i dati provenienti non solo dai DB ma anche da qualunque applicazione come Word, Excel, Outlook. Ci troveremo quindi in un futuro molto prossimo a collegare non solo database ma qualunque applicazione OLE-DB compatibile. Dal canto suo la Microsoft sta spingendo molto per raggiungere la massima diffusione di UDA e vedrete che in poco tempo ogni applicazione avrà il suo bel driver OLE-DB esattamente come adesso ha quello ODBC. Se pensate che questo non sia abbastanza per abbandonare i vostri vecchi metodi di programmazione tenetevi forte perché la tabella che segue vi sbalordirà più di 1000 parole:
| Confronto prestazioni - Access | ||
| OLE-DB | ODBC (DSN) | |
| Tempo di connessione | 18 | 82 |
| Tempo di iterazione su 1000 Record | 2900 | 5400 |
| Confronto prestazioni - SQL server | ||
| OLE-DB | ODBC (DSN) | |
| Tempo di connessione | 62 | 99 |
| Tempo di iterazione su 1000 Record | 100 | 950 |
