| 
 | |||||||
| 
 | 
|  | 
|  | 
|  | Strumenti | 
|  21-02-2008, 18:10 | #1 | 
| Junior Member Iscritto dal: Jul 2006 
					Messaggi: 12
				 | 
				
				[DB] Singolo vs Multipli DB
			 
		Ciao a tutti, Sto lavorando ad un progetto nel quale per farla semplice viene supportata la creazione di ontologie. Tutte le informazioni di queste ontologie vengono memorizzate in un db relazionale (postgresql). Abbiamo già lo schema per una singola ontologia (fin'ora nel sistema ne veniva utilizzata solo una), il problema si pone quando dobbiamo supportare la creazione a runtime di diverse ontologie. L'idea iniziale era quella di ampliare lo schema aggiungendo alle varie tabelle una fk che puntasse all'id dell'ontologia, sfortunatamente ogni ontologia può contenere molti dati, quindi con il crescere dell'informazione il tutto diventerebbe più lento, e gestire una singola ontologia potrebbe diventare problemantico e inutile (visto che ogni ontologia e completamente slegata dalle altre). Un alternativa è quella di creare per ogni ontologia il suo set di tabelle identificate dall'id della stessa nello stesso DB. L'ultima che mi viene in mente (ed è la direzione che stiamo prendendo) è quella di creare un db per ogni ontologia, qua il problema è che se abbiamo 1000 ontologie avremmo 1000 DB e 1000 connessioni (anche se in realtà è tutto distribuito su più server) e creare un DB è di solito un operazione lenta (5 secondi per postgresql!!). Sinceramente però non sono troppo convinto e non riesco ad identificare i vari punti di forza dei vari approcci. Quindi vi chiedo, voi come affrontereste la cosa? Avete qualche articolo da indicarmi sul problema? Qualche consiglio? | 
|   |   | 
|  21-02-2008, 21:32 | #2 | 
| Senior Member Iscritto dal: May 2004 Città: Londra (Torino) 
					Messaggi: 3692
				 | 
		Ciao. Io userei un unico DB, ma con l'opzione di partizionamento delle tabelle, che ho visto esistere anche in Postgres. http://www.postgresql.org/docs/curre...titioning.html In pratica puoi decidere alcuni criteri per partizionare logicamente ogni tabella, come se fossero tante tabelle separate, ma pur risiedendo sulla stessa tabella fisica. In questo modo unisci l'utilita' di avere tutto nello stesso database (meno complessita' da gestire, meno query da scrivere, meno manutenzioni, etc.) con la velocita', essendo logicamente come se fossero tante tabelle in partizioni separate. Se invece che Postgres poteste usare Oracle (esiste anche una versione Oracle Express gratuita, con ovviamente qualche limitazione), ciascuna partizione potrebbe anche stare su dischi separati. Avreste il supporto al FullText indexing e anche all'opzione relative alle librerie sulle Tassonomie e Ontologie gia' integrata nella parte di Full Text indexing del motore. 
				__________________ Se pensi che il tuo codice sia troppo complesso da capire senza commenti, e' segno che molto probabilmente il tuo codice e' semplicemente mal scritto. E se pensi di avere bisogno di un nuovo commento, significa che ti manca almeno un test. | 
|   |   | 
|  22-02-2008, 10:42 | #3 | 
| Junior Member Iscritto dal: Jul 2006 
					Messaggi: 12
				 | 
		Ciao, Grazie per la risposta. Il fatto è che vorremmo essere il più indipendenti possibili da meccanismi interni al DBMS (usiamo jdbc). In realtà per noi è più comodo avere più DB (il codice attuale sarebbe riutilizzabile al 100%), in dal mio punto di vista è più comodo da mantenere, per esempio se voglio portarmi dietro una sola ontologia, ho già il db pronto per essere usato.. Comunque approfondisco la cosa del partizionamento, Grazie! | 
|   |   | 
|   | 
| Strumenti | |
| 
 | 
 | 
Tutti gli orari sono GMT +1. Ora sono le: 03:20.









 
		 
		 
		 
		






 
  
 



 
                        
                        










