I database orientati agli oggetti sono ancora in uso?

Question

Molto tempo fa, ho sentito parlare dei database degli oggetti. Concetto fantastico e tutto. Ora, con l'evento degli ORM ovunque, qualcuno usa ancora qualcuno dei sistemi di database orientati agli oggetti? Sono rilevanti? Sono pratici?

Answer 1

I database OO non sono mai usciti da un mercato di nicchia. Sono utili per alcune applicazioni - in cui la struttura dei dati si presta ad essere rappresentata da un grafico a oggetti - ma non hanno mai avuto il vantaggio convincente su un RDBMS di attraversare il burrone. Il vantaggio principale propagandato per i prodotti OODBMS è la stretta integrazione con la lingua host: non vi è alcuna discrepanza tra oggetto e impedenza relazionale.

Tuttavia, ci sono ancora diversi venditori OODBMS come Gemstone , Versant o Cardinal che sono facendo abbastanza bene con i loro prodotti. La tecnologia è utile per alcuni tipi di strutture dati e può essere più efficiente di un RDBMS ma tende a essere debole per le query ad hoc rispetto ai moderni dialetti SQL.

Come vari others hanno notato che Gemstone sta attirando un po 'di attenzione a causa del loro supporto per Seaside e Maglev (una porta di Ruby sulla VM Gemstone con Rails in esecuzione su di esso). Potremmo scoprire che questo attira l'attenzione della gente simpatica di Gemstone e con essa un po 'più di attenzione al paradigma OODBMS.

Answer 2

  

In effetti, i sistemi di database sono uno dei   le aree che sono i cambiamenti fondamentali   davvero difficile. Miliardi di dollari lo sono   speso in sistemi di database relazionali   e stanno lavorando abbastanza bene.

Nella vita reale, semplicemente non è vero. Uno dei motivi principali dei nostri problemi con i database (ho riscontrato che il 30% di tutte le righe del database contiene errori) è l'uso di una digitazione molto primitiva e la convalida in SQL. Inoltre, anche se sono chiamati relazionali, sono molto cattivi nel gestire le relazioni. Il risultato sono modelli di dati denormalizzati e errori di aggiornamento risultanti.

Il motivo per cui alle aziende piacciono i database relazionali è perché sono molto prevedibili. Devono spendere un sacco di soldi per loro, hanno bisogno di molti sviluppatori e manutentori che svolgono principalmente lavori di routine. Non riescono a vedere la quantità di duplicazione che potrebbe essere eliminata come un vantaggio. Il lavoro di routine consente agli sviluppatori di assorbire i rischi del lavoro difficile. Passare a un OODB manterrebbe il lavoro meno prevedibile.

Answer 3

Guarda db4o .

Answer 4

In effetti, i sistemi di database sono una delle aree in cui i cambiamenti fondamentali sono davvero difficili. Miliardi di dollari vengono spesi per sistemi di database relazionali e funzionano abbastanza bene. Sono una tecnologia collaudata e sono stati abbastanza flessibili da soddisfare la maggior parte delle esigenze (ad esempio utilizzando ORM, come hai detto). Database di oggetti esistono effettivamente, anche al di fuori del mondo accademico. Ma non aspettarti di vedere qualcosa di così grande come SQL Server o Oracle in quell'area in qualunque momento presto. Esistono come teoria e come piccoli database specifici dell'applicazione e vari prodotti. Fondamentalmente, prevedo che i database relazionali diventeranno più orientati agli oggetti in futuro per gestire meglio i requisiti.

Answer 5

Ho iniziato a usare Gemstone di recente. GLASS (Gemstone su Linux (o OS-X) con Seaside (smalltalk web framework)) è probabilmente il miglior ambiente di sviluppo web per applicazioni complesse. Smalltalk sta facendo un risveglio, essendo & Quot; il vero rubino & Quot ;.

Il supporto per le modifiche dello schema e l'interrogazione è di gran lunga superiore a quello in RDBMS.

Una differenza importante è che questa volta sono convenienti.

Answer 6

Utilizziamo Versant Object Database nel prodotto su cui lavoro. (Precedentemente FastObjects, precedentemente database Poet). È un database di oggetti e scopriamo che funziona molto meglio di un modello relazionale per alcuni aspetti del nostro prodotto, principalmente archiviando oggetti di configurazione, interfacciarsi con il codice Java.

Vedi anche questa domanda precedentemente posta: https://stackoverflow.com/questions/52144/object- -di database oriented-esperienze

Answer 7

Perché il costo del loro software non è abbastanza facile da scoprire.

Ho verificato Objectivity, db4o, versant e nessuno di loro ha il prezzo del software in anticipo sul loro sito web.

Ho già quasi perso interesse solo per questo.

Qualcuno sa da qualche parte dove c'è un confronto dei prezzi e delle licenze di tutti questi diversi ood?

Answer 8

Utilizzo di GemStone per un'applicazione aziendale di grandi dimensioni. È fantastico ed è molto pratico. Lo usiamo da diversi anni e in quel periodo ci ha permesso di fare molto con pochissime risorse. Sfortunatamente ci sono e ci sono state numerose idee sbagliate sui database degli oggetti e penso che ciò li renda meno rilevanti nel mondo degli affari. Speriamo che qualcosa come GLASS (GemStone, Linux e Seaside Smalltalk) cambierà questo in futuro.

Answer 9

Il database degli oggetti è finora un concetto interessante. Tuttavia, le implementazioni sono corredate di problemi di scalabilità e stabilità. Ora con l'incarnato giusto che si rivolge a queste due bestie, l'equazione potrebbe cambiare.

Quello che pensavo fosse, un Data Engine (non necessariamente Object Database) e RDBMS possono davvero vivere fianco a fianco, infatti, c'è un ottimo posto per un Data Engine nel Middle-Tier, App / sistemi integrati. .. Inoltre, una corretta implementazione di un motore di dati consentirà il supporto sia per la persistenza degli oggetti a livello basso che a livello superiore, costrutti RDBMS / SQL. Ciò significa che l'applicazione può scegliere di lavorare con gli oggetti, utilizzare il motore di dati per la persistenza degli oggetti E rendere gli oggetti disponibili come righe / colonne di una tabella tramite un'interfaccia RDBMS.

Questa è la configurazione ideale. Colleghiamo le due tecnologie e forniamo agli sviluppatori alternative da programmare nella loro interfaccia preferita. Si potrebbe obiettare che ora abbiamo questo, ad es. - SQL Server ha il supporto per l'hosting di oggetti CLR, MA le attuali implementazioni soffrono di rallentamento dell'impedenza. vale a dire - nel percorso dei dati ci sono molte conversioni / traduzioni come Oggetti! = dati bidimensionali, quindi quando la tua App che si occupa di Oggetti li salva in DB, la soluzione deve convertirli / tradurli in file di riga in una tabella.

MA se invertiamo la situazione, vale a dire - il motore di dati funziona su Oggetti, non si verificherà alcuna discrepanza di impedenza. L'aggiunta di proiezioni di dati bidimensionali non è altro che l'implementazione dell'interfaccia di una collezione Objecct, quindi non c'è davvero alcuna mappatura / traduzione che si verifica quando gli oggetti sono esposti come righe di dati di una tabella. Questa è la mia teoria.

Quindi forse la prossima ondata di tecnologia in quest'area è un motore di dati che consentirà a Oggetti come interfaccia di basso livello e interfaccia RDBMS posizionata sopra di essa. E questa tecnologia è ora disponibile!

La persistenza dell'oggetto scalabile B-Tree Gold versione 4.0 ha questo obiettivo principale di progettazione. Raggiunge le seguenti caratteristiche e, quindi, è ben adattato per essere il motore di dati preferito per il prossimo RDBMS, che fondamentalmente è uno strato sopra di esso. Due dei suoi principali punti chiave sono: Scalabilità: 100 milioni di inserti in 17 ore in un laptop normale / equipaggiato con media. Stabilità: transazione di forza industriale che garantirà che DB non sia danneggiato e che possa tornare a uno stato precedentemente impegnato.

Perché questo funzioni, il motore di dati deve soddisfare la scalabilità e la stabilità richieste dai server RDBMS. Un compito molto difficile ma non impossibile. B-Tree Gold versione 4.0 SOP ha soddisfatto questo requisito, quindi, siamo davvero pronti ad implementare questo tipo di soluzione, senza davvero infilarlo sotto il collo poiché SOP offre la libertà di scelta su come desideri utilizzarlo. Può essere utilizzato in molti modi, ad es. - integrare i server RDBMS come stazione di cache di livello intermedio, DB incorporato nel lato client, ecc ... per non parlare del motore di dati di basso livello del server RDBMS stesso!

Answer 10

Almeno dal mio punto di vista sono praticamente morti. Ma poi sto lavorando principalmente nel software commerciale. Forse nelle aree accademiche sono ancora in uso da qualche parte.