««« | »»»
DBMS per XML: lo stato dell’arte
Sempre a proposito dei limiti dei database relazionali, ecco un post interessante di Elliotte Rusty Harold in cui, facendo una carrellata sull’offerta dei database XML dice:
IMHO, native XML databases are now roughly where relational databases were circa 1994: solid, proven technology that gets the job done but only if you pay big bucks to do it.
e più oltre:
The simple truth is that while much data and many applications fit very neatly into tables, even more data doesn’t. Books, encyclopedias, web pages, legal briefs, poetry, and more is not practically normalizable. SQL will continue to rule supreme for accounting, human resources, taxes, inventory management, banking, and other traditional systems where it’s done well for the last twenty years. However, many other applications in fields like publishing have not even had a database backend. It’s not that they didn’t need one. It’s just that the databases of the day couldn’t handle their needs, so content was simply stored in Word files in a file system. It is these applications that are going to be revolutionized by XQuery and XML.
Tuttavia non sono ancora convinto che questo sia vero. La questione, secondo me, gira sempre intorno alla fatto di considerare l’XML un data type o meno: se sì, allora gli RDBMS potrebbero tranquillamente integrarne la gestione, altrimenti serve qualcos’altro, come i prodotti che il post citato elenca.
Aggiungo anche che la prima possibilità – l’XML come data type – vale solo se l’ipotesi per cui il modello relazionale e i data types sono realmente ortogonali; cosa di cui non sono sicurissimo. È vero, la teoria dice così ma ci sono diverse altre questioni che non possono essere ignorate: il fatto che i database attuali, basati sull’SQL, non sono implementazioni fedeli del modello relazionale; il fatto che ci sono problemi di ordine strettamente pratico che vanno tenuti in considerazione.
L’esempio classico è l’eterno dilemma del “dove–salvo–le–foto” e ogni volta vengono fatti elenchi di pro e contro le soluzioni basate su database e su file system. Non basta solo l’ortogonalità (presunta) a dirimere la questione, bisogna considerare anche questioni come il backup e le prestazioni nel servire le foto. Credo che la risposta formalmente corretta è quella che non basta definire un data type BLOB e buttarci dentro quello che si vuole; servono anche degli operatori adeguati e la cosa non è affatto banale.
Lo stesso potrebbe valere per l’XML inteso come data type: è pratico pensare di salvare in solo campo un testo di 250 pagine? Quali criteri usiamo?
Per proseguire
Commenti e trackback sono disabilitati.