Quali sono i pro e i contro dei database a oggetti?

Question

Sono disponibili molte informazioni sui mappatori relazionali a oggetti e su come evitare al meglio il disadattamento di impedenza, che sembrano tutti punti controversi se si dovesse utilizzare un database di oggetti.La mia domanda è: perché non viene utilizzato più frequentemente?È per motivi di prestazioni o perché i database di oggetti fanno sì che i tuoi dati diventino proprietari della tua applicazione o è dovuto a qualcos'altro?

Answer 1

• Familiarità. Gli amministratori di database conoscono i concetti relazionali;quelli oggettivi, non tanto.
• Prestazione. È stato dimostrato che i database relazionali si adattano molto meglio.
• Scadenza. SQL è un linguaggio potente e sviluppato da molto tempo.
• Supporto del venditore. Puoi scegliere tra molti più strumenti di prima parte (server SQL) e di terze parti (interfacce amministrative, mappature e altri tipi di integrazione) rispetto a OODBMS.

Naturalmente, il modello orientato agli oggetti è più familiare al sviluppatore, e, come fai notare, risparmierei uno degli ORM.Ma finora il modello relazionale si è rivelato l’opzione più praticabile.

Vedi anche la recente domanda, Database orientati agli oggetti e relazionali.

Answer 2

Sto usando db4o che è un OODB e risolve la maggior parte dei contro elencati:

• Familiarità: i programmatori conoscono il loro linguaggio meglio di SQL (vedi Query native)
• Prestazioni: questo è altamente soggettivo ma puoi dare un'occhiata Pole position
• Supporto e maturità del fornitore: possono cambiare nel tempo
• Non può essere utilizzato da programmi che non utilizzano lo stesso framework: esistono standard OODB e puoi utilizzare quadri diversi
• Il controllo delle versioni è probabilmente un po' una stronzata: il controllo delle versioni lo è in realtà Più facile!

I pro che mi interessano sono:

• Query native: Db4o ti consente di scrivere query nel tuo linguaggio di tipizzazione statica in modo da non doverti preoccupare di digitare in modo errato una stringa e di trovare dati mancanti in fase di runtime,
• Facilità d'uso - La definizione della logica aziendale nel livello del dominio, nel livello di persistenza (mappatura) e infine nel database SQL rappresenta sicuramente una violazione di DRY.Con OODB definisci il tuo dominio a cui appartiene.

Sono d'accordo: gli OODB hanno molta strada da fare ma stanno andando avanti.E ci sono problemi di dominio che possono essere risolti meglio da OODB,

Answer 3

Un'obiezione ai database di oggetti è che creano uno stretto accoppiamento tra i dati e il codice.Per alcune app questo potrebbe andare bene, ma non per altre.Una cosa bella che ti dà un database relazionale è la possibilità di inserire molte visualizzazioni sui tuoi dati.

Ted Neward spiega questo e molto altro sugli OODBMS molto meglio di così.

Answer 4

Non ha nulla a che fare con le prestazioni.Vale a dire, praticamente tutte le applicazioni funzionerebbero meglio con un OODB.Ma ciò metterebbe anche molti DBA senza lavoro o costretti a imparare una nuova tecnologia.Ancora più persone rimarrebbero senza lavoro per correggere gli errori nei dati.È improbabile che ciò renda gli OODB popolari tra le aziende affermate.Gavin sembra essere totalmente all'oscuro, un collegamento migliore sarebbe Kirk

Answer 5

Contro:

• Non può essere utilizzato da programmi che non utilizzano anche lo stesso framework per accedere all'archivio dati, rendendo più difficile l'uso in tutta l'azienda.

• Meno risorse disponibili online per il database non basato su SQL

• Nessuna compatibilità tra i tipi di database (non è in grado di scambiare un diverso provider DB senza modificare tutto il codice)

• Il versioning è probabilmente un po 'una cagna.Immagino che l'aggiunta di una nuova proprietà a un oggetto non sia così facile come l'aggiunta di una nuova colonna a una tabella.

Answer 6

Soren

Tutti i motivi che hai indicato sono validi, ma vedo che il problema con OODBMS è il modello logico dei dati.Il modello a oggetti (o meglio il modello a rete degli anni '70) non è semplice come quello relazionale, ed è quindi inferiore.

Answer 7

Jodonnel, non vedo come l'uso dei database di oggetti accoppia il codice dell'applicazione ai dati.Puoi comunque astrarre la tua applicazione dall'OODB utilizzando un modello di repository e sostituirla con un database SQL supportato da ORM se progetti le cose correttamente.

Per un'applicazione OO, un database OO fornirà un adattamento più naturale per gli oggetti persistenti.

Ciò che probabilmente è vero è che colleghi i tuoi dati al tuo modello di dominio, ma questo è il punto cruciale!

Non sarebbe utile avere un unico modo di considerare dati, regole aziendali e processi utilizzando una visione incentrata sul dominio?

Quindi, un grande vantaggio è che un OODB corrisponde al modo in cui sono progettate le più moderne applicazioni software orientate agli oggetti di livello aziendale, non vi è alcuno sforzo aggiuntivo per progettare un livello dati utilizzando un design (relazionale) diverso.Più economico da costruire e mantenere e in molti casi con prestazioni generali più elevate.

Contro, solo una generale mancanza di maturità e adozione, suppongo...