Newsgroup: it.comp.software.database
Titolo: Rappresentare in maniera tipata i file di un computer, object-relational mapping oppure...

Ciao a tutti, devo rappresentare su un db relazionale i file di un computer,
in maniera tipata. Vorrei avere una rappresentazione gerarchica del tipo i
file, poi i file audio, poi gli mp3 e gli ogg allo stesso livello. Ora,
naturalmente, non dovendo io rappresentare solo i tipi, ma anche i nomi dei
file, se no un database che lo tengo a fare, viene da se che normalmente un
file mp3 non sarà sia nella tabella "mp3" che nella tabella "file audio",
ma solo in quella mp3. Questo sempre che io usi una tabella apposita. 
Cmq scusate la lunghezza del post e la newbiezza di tutte le cose che
scrivo, sto cercando di capire dove devo orientare lo studio.
Problema [numero uno, ce n'erano altri ma già così è lungo :) ]: Vorrei
poter estendere l'architettura a runtime. Se faccio una tabella con, per
dire, tre o quattro colonne, può sempre venire fuori in un secondo momento
un'altra tabella che ha solo due campi in comune. E allora cosa devo fare
per avere facilmente a disposizione in una query la parte comune di _tutte_
le tabelle che in un certo momento dell'esecuzione del database possono
essere state create?
Esempio: creo la tabella "ogg" e la tabella "mp3", entrambe hanno autore,
titolo e bitrate. Probabilmente farei meglio a fare una tabella che ha
autore, titolo e bitrate e poi a metterci le tabelle "ogg" e "mp3" con
chiave esterna in questa. Ma se poi vengono fuori altri tipi di file, uno
con "bitrate e titolo", un altro con "bitrate e autore" e così via? Dovrei
spostare i file in una tabella più in alto e fare le chiavi esterne, ma è
scomodo. 
Questo problema, secondo me, è simile a quello che si ha in programmazione a
oggetti quando si sente il bisogno del "superclassing" perchè il
programmatore della libreria non ha previsto i nostri bisogni. E infatti io
il db lo devo dare a mo' di libreria che potrà essere estesa con l'aggiunta
di nuovi tipi di file. 
Il linguaggio ocaml risolve brillantemente questo problema, perchè ricava il
tipo dei parametri delle funzioni nella parte a oggetti guardando i soli
metodi usati nel corpo, e non il tipo dei parametri, come se fossero
definite a priori tutte le possibili sovraclassi di ogni classe e come se
l'avere un tipo in comune dipende dal fatto di avere metodi con lo stesso
nome e lo stesso tipo.
Visto che l'object-relational mapping uno lo fa una volta e basta, mi
piacerebbe riuscire a fare la stessa cosa. Scusate la divagazione.
Avevo pensato alle estensioni a oggetti di postgres, ma poi ho visto che
nelle sottoclassi non è richiesto il rispetto dei vincoli. E ci sono
rimasto maluccio, ma normalmente il sistema a oggetti di postgres è usato?
Cmq non ho ancora controllato che postgres consenta il superclassing.
Ciao
Vincenzo

 ha scritto nel
messaggio news:iewOc.59438$OR2.3...@news3.tin.it...

e' piu una cosa da brain
http://www.thebrain.com


 
http://www.thebrain.com
Beh, considerato che sto scrivendo un filesystem per linux rilasciato sotto
GPL direi di no, ma questo non l'avevo detto quindi è colpa mia :) In ogni
caso io vorrei "solo" rappresentare una gerarchia di tipi su un db sql, non
cercare soluzioni alternative.
V.

 V.

 scopo
Si vero, infatti per quello vorrei che i dati fossero su disco, memorizzati
in un "vero" filesystem su cui è posto l'altro, ora devo cercare di capire
bene quello che posso ottenere dal benedetto modello di dati, nel frattempo
posto un'altra domanda in un altro thread :)
V.