Newsgroup: it.comp.software.database
Titolo: database XML

Saluti.
Ultimamente sembra si siano fatti dei passi in avanti verso lo
sviluppo di database XML nativi.
Cosa ne pensate?
Come praticita' mi sembrano una valida alternativa ai database
relazionali.
Ma come e' la situazione dal punto di vista delle prestazioni e della
affidabilita' dei dati?
Grazie  Manlio Perillo

affidabilita' dei dati?
Le prestazioni saranno catastrofiche trattandosi di dati in formato
testo.
jk
// Jilani KHALDI
http://jkhaldi.oltrelinux.com


Ho scaricato il database XML della SleepCat;
voglio fare alcuni test.
Saluti e grazie  Manlio Perillo

 affidabilita' dei dati?
Dipendente dal singolo prodotto acquistato, e comunque non di primaria
importanza IMHO.
L'XML č meglio che resti solo un formato per i dati.
ciao


In realta' probabilmente basta solo del supporto all'XML su un
database relazionale esistente.
Come ad esempio il modulo xml2 di PostgreSQL.
In generale, il problema che mi ponevo era il seguente.
Supponiamo di avere un database per catalogare un magazzino.
Oltre a dei dati in comune, i vari articoli (libri, DVD) hanno
strutture diverse.
Una soluzione e' usare l'ereditarieta' in SQL, ma e' una tecnologia
ancora troppo recente.
Un'altra soluzione e' creare una tabella tipo:
CREATE TABLE attributes (
id PRIMARY KEY,
ref FOREIGN KEY,
type TEXT,
value TEXT
);
Ad esempio, per un libro, si possono avere le coppie
numero_pagine->300, etc.
Il problema e' che cosi' si perde la struttura (se c'e' ne una).
Un'altra soluzione e' usare, al posto di type/value, un documento XML.
CREATE TABLE attributes (
id PRIMARY KEY,
ref FOREIGN KEY,
instance TEXT
);
Come accennato, PostgreSQL permette di fare qualche cosa tipo:
SELECT * FROM
xpath_table('article_id', 
	'article_xml',
	'articles', 
	'/article/author|/article/pages|/article/title',
	'date_entered > ''2003-01-01'' ') 
AS t(article_id integer, author text, page_count integer, title text);
Il problema (non grave?) e' l'efficienza.
Mi chiedevo se fosse possibile usare un tipo apposito, al posto di
TEXT, per memorizzare il documento XML; 
Questo permetterebbe di 'precompilare' il documento.
Come e' la situazione per gli altri database?


 Saluti e grazie  Manlio Perillo
XML dovrebbe essere usato solo come veicolo di scambio dati.
E' possibile produrre dati in XML, e accettare dati in XML per
inserirli nel DB, ma la registrazione dovrebbe essere tenuta in
formato nativo.
Vedi, ad esempio, questo motore, che trasforma dinamicamente da
dataset complesso a XML (e altri formati):
http://gmax.oltrelinux.com/cgi-bin/xtab.cgi
Se pensi che un database XML sia una buona idea, leggi questi link:
http://www.dbazine.com/ofinterest/oi-articles/pascal2
http://www.tbray.org/ongoing/When/200x/2003/03/16/XML-Prog
(Nota: il secondo articolo e' scritto da uno dei creatori di XML)
ciao
gmax
-- 
  _  _ _  _
(_|| | |(_|><
  _|
http://gmax.oltrelinux.com


Potrebbe essere vero in generale.
Pero', come detto, l'uso che intendevo farne era per memorizzare degli
attributi aggiuntivi nel modo migliore.
Quale altro metodo esiste?
Ad esempio, supponi che lo schema del database sia:
CREATE TABLE Articoli(
id PRIMARY KEY,
bar_code TEXT,
title TEXT,
description TEXT
);
e volessi inserire dati addizionale per i diversi articoli (che sono
tutti diversi e quindi non definibili in un unica tabella).
Nel caso di un libro, tipo di rilegatura, numero di pagine, etc.
Nel caso di DVD, lingue disponibili, sottotitoi, tipo DVD (DVD5/DVD9)
etc.


 Il problema (non grave?) e' l'efficienza.
Per me il problema è prima di tutto l'integrità dei dati e l'utilità
di un sistema informativo.
ciao!

 etc.
Il modello relazionale gestisce questo tipo di "dati addizionali" usando
tabelle correlate, appunto perche', se mettessimo i dati in un'unica tabella,
avremmo problemi di ridondanza e integrita'.
Se usi un relazionale, sei sicuro di avere la massima flessibilita' nell'accesso
ai dati e hai tutti i mezzi per garantire l'integrita' dei dati.
Il prezzo da pagare e' capire la logica relazionale.
Chi propone database XML o database a oggetti non fa altro che riproporre,
sotto altro nome, i database gerarchici, che sono piu' semplici da capire
ma un disastro da mantenere.



Ed infatti una delle soluzioni che avevo pensato era (sintassi non
verificata):
CREATE TABLE Attributes (
id PRIMARY KEY,
ref FOREIGN KEY REFERENCES Articoli(id),
type TEXT,
value TEXT
);
La cosa pero' e' troppo generica.
Potrei definire altre tabelle tipo.
CREATE TABLE DVD (
id FOREIGN KEY REFERENCES Articoli(id),
...
);
CREATE TABLE Book (
id FOREIGN KEY REFERENCES Articoli(id),
...
);
Pero' non sono sicuro sia la cosa migliore e se e' flessibile.
Saluti  Manlio Perillo


Io stavo cercando una soluzione ottimale usando un rdbms.
L'unica cosa che mi viene in mente e' fare:
CREATE TABLE Articoli(
id PRIMARY KEY,
type TEXT,  /* il tipo di oggetto, ex DVD, Book */
bar_code TEXT,
 
title TEXT,
description TEXT
);
CREATE TABLE DVD (
id FOREIGN KEY REFERENCES Articoli(id),
...
);
CREATE TABLE Book (
id FOREIGN KEY REFERENCES Articoli(id),
...
);
Ossia per le query di base uso Articoli.
Se poi voglio le informazioni addizionali, in base al valore di type,
uso le altre tabelle.
Sinceramente pero' non so se e' un approccio valido.


 Sinceramente pero' non so se e' un approccio valido.
Beh, diciamo così: se capita a tiro un relational-purist ci frigge
sulla graticola per quello che siamo dicendo... :-)
Questo tipo di design è un 'errore' comune abbastanza da avere un
nome tutto suo, ossia "EAV error" (entity-value-attribute).
Premesso che comunque troveresti da solo su Google varia letteratura
su quest'argomento ("generic modeling"), e premesso che tali articoli
dovrebbero restare in copia singola rinchiusi all'ultimo piano di
qualche monastero, al cui accesso controllato provvede un bibliotecario
cieco, procediamo pure :-)
Lo schema che tu disegnerai si situa tra la soluzione minimale di
tipo foglio elettronico (id-tipoattributo-valore), e il non-plus-ultra
descritto in questo articolo di Miley:
www.inconcept.com/JCM/June2001/miley.html
 (supporto per tipi, multiple
inheritance etc).
Facendo così però si usa il motore del db per fare cose per il quale
non è stato progettato.
Ti consiglio di valutare attentamente, magari per il tuo obiettivo un
rdbms non è la cosa migliore.
ciao!
ps: ti bastano pochi cambiamenti per far diventare il tuo schema al
100% relazionale


Eliminare le informazioni in piu' non uniformi? :-)


 Saluti e grazie  Manlio Perillo
Ciao e buon lavoro!


Ma non e' proprio quello che avevo fatto io? :-)
Il problema che ci vedo e' che, per il supporto a questa soluzione, e'
necessario un linguaggio 'esterno'.
Stesso problema, credo, che si ha con l'ereditarieta'.
Per ricavare le informazioni base + quelle extra, devo per forza
conoscere a priori le tabelle addizionali e fare delle query apposite
per ognuna di questa.


 Saluti e grazie  Manlio Perillo
Ciao!


Era proprio quello che volevo fare.


 Un serial o altro per identificare univocamente un articolo.
Se ti riferisci ad un contatore autoincrementante (il datatype messo
a disposizione in varie salse nei db), è sicuramente errato.
Ciao!