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

Question

C'è un sacco di informazioni là fuori sui mappatori relazionali di oggetti e su come evitare al meglio la mancata corrispondenza dell'impedenza, che sembrano essere punti moot se si dovesse usare un database di oggetti. La mia domanda è: perché questo non viene usato più frequentemente? È dovuto a motivi di prestazioni o perché i database degli oggetti fanno sì che i tuoi dati diventino proprietari della tua applicazione o dipendono da qualcos'altro?

Answer 1

• Familiarità. Gli amministratori di database conoscono concetti relazionali; quelli oggetto, non così tanto.
• Prestazioni. È stato dimostrato che i database relazionali hanno una scala di gran lunga migliore.
• Scadenza. SQL è un linguaggio potente e di lungo sviluppo.
• Supporto fornitore. È possibile scegliere tra molti più strumenti di prima parte (server SQL) e di terze parti (interfacce amministrative, mapping e altri tipi di integrazione) rispetto a OODBMS.

Naturalmente, il modello orientato agli oggetti è più familiare al sviluppatore, e, come fai notare, avrebbe risparmiato un ORM. Ma finora, il modello relazionale ha dimostrato di essere l'opzione più praticabile.

Vedere anche la domanda recente, Object Orientated vs Relational Databases.

Answer 2

Contro:

• Non può essere utilizzato dai programmi che non usano anch'essi lo stesso quadro per l'accesso all'archivio dati, rendendo più difficile da usare in tutto il impresa.

• Meno risorse disponibili on-line per non basato su SQL database di

• No compatibilità tra di database tipi (non può scambiare per un diverso fornitore di db senza cambiare tutto il codice )

• Il versioning è probabilmente un po 'di una cagna . Direi che aggiungere una nuova proprietà a un oggetto non è esattamente come come aggiungere una nuova colonna a una tabella .

Answer 3

Un'obiezione ai database di oggetti è che crea un accoppiamento stretto tra i dati e il codice. Per alcune app questo può essere OK, ma non per gli altri. Una cosa carina che ti offre un database relazionale è la possibilità di mettere molti punti di vista sui tuoi dati.

Ted Neward spiega questo e molto altro su OODBMS molto meglio di questo.

Answer 4

Sören

Tutte le ragioni che sono valide, ma vedo il problema con OODBMS è il modello logico dei dati.Il modello oggetto (o piuttosto il modello di rete degli anni '70) non è semplice come quello relazionale ed è quindi inferiore.

Answer 5

ho usato db4o che è un OODB e risolve la maggior parte dei cons elencate:

• Familiarità - programmatori conoscono la loro lingua meglio di SQL (vedi query nativi)
• Prestazioni - questo uno è molto soggettiva, ma si può dare un'occhiata a PolePosition
• supporto del fornitore e la maturità - può cambiare nel corso del tempo
• non può essere usato da programmi che non utilizzano anche lo stesso quadro - ci sono gli standard OODB e si può utilizzare different frameworks
• Il versioning è probabilmente un po 'pignolo - Il versionamento è in realtà easier!

I pro che mi interessano sono:

• query nativi - db4o permette di scrivere query nella tua lingua digitato statico in modo da non dovete preoccuparvi di errori di digitazione di una stringa e trovare dati mancanti in fase di esecuzione,
• Facilità di utilizzo: definizione della logica di buissiness nel livello dominio, livello di persistenza (mapping) e infine il database SQL è sicuramente una violazione di DRY. Con OODB definisci il tuo dominio a cui appartiene.

Sono d'accordo - OODB ha una lunga strada da percorrere ma stanno andando. E ci sono problemi di dominio là fuori che sono meglio risolti da OODB,

Answer 6

jodonnel, non vedo come l'uso dei database oggetto accoppi il codice dell'applicazione ai dati. È ancora possibile astrarre l'applicazione da OODB utilizzando un modello di repository e sostituirlo con un database SQL con back-up ORM se si progettano le cose correttamente.

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

Ciò che è probabilmente vero è che si collegano i dati al modello di dominio, ma questo è il punto cruciale!

Non sarebbe opportuno disporre di un unico modo per esaminare sia i dati, le regole aziendali e i processi che utilizzano una vista incentrata sul dominio?

Quindi, un grande vantaggio è che un OODB corrisponda a come sono progettate le più moderne applicazioni software orientate agli oggetti di livello enterprise, 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 prestazioni generali più elevate.

Contro, appena generale mancanza di maturità e l'adozione mi sa ...

Answer 7

Non ha nulla a che fare con le prestazioni. Vale a dire, in pratica tutte le applicazioni funzionerebbero meglio con un OODB. Ma questo metterebbe anche fuori lavoro molti DBA/dovendo imparare una nuova tecnologia. Ancora più persone sarebbero senza lavoro correggendo gli errori nei dati. È improbabile che gli OODB diventino popolari con le aziende affermate. Sembra che Gavin sia totalmente privo di senso, un collegamento migliore sarebbe Kirk