Perché i database orientati agli oggetti non hanno avuto successo (ancora)? [chiuso]

Question

Questa è la domanda. Fornisci solo una ragione per cui pensi che OODB sia fallito o perché molti sistemi oggi utilizzino ancora database relazionali.

Answer 1

Possiamo rispondere più di una volta? Un'altra ragione è che i DB relazionali hanno solide basi in matematica: dalla definizione di una relazione, fino alle forme normali, la teoria è solida come una roccia. È vero che il modello relazionale non si associa bene a OO, ma IMHO i vantaggi e la stabilità di quel modello superano il problema della mappatura.

Answer 2

Il motivo principale è SQL. È molto utile essere in grado di utilizzare i dati da un database in altri contesti al di fuori dell'applicazione, e spesso con database di oggetti i dati vengono archiviati in un formato che non può essere facilmente interrogato. Con un database relazionale i dati possono diventare parte di un data warehouse, ad esempio, o semplicemente interrogati da amministratori di sistema ecc.

Answer 3

Penso che sia perché " database di oggetti " stanno risolvendo un problema che (quasi) nessuno ha davvero. Per una semplice persistenza dei grafici a oggetti, la serializzazione incorporata nella maggior parte degli ambienti OO è "abbastanza buona". Se si desidera eseguire operazioni sofisticate su un sottoinsieme dei dati, un database relazionale e SQL sono perfetti.

Oltre ad alcune applicazioni marginali (enormi grafici a oggetti che non possono essere conservati in memoria, ma per i quali le relazioni non si semplificano bene per l'uso di RDBMS), non c'è davvero bisogno di questi strumenti.

Answer 4

Solo perché gli OODB non sono il mainstream dovremmo comunque considerare i successi che hanno avuto. Cache e Zope sono entrambi ampiamente utilizzati (relativamente) ma sarebbero considerati di successo da alcuni standard.

Forse la ragione principale per cui OODB non si è impadronito in modo drammatico è il successo dei sistemi ibridi relazionali di oggetti che prendono la maggior parte del potenziale market share da OODB: PostgreSQL e Informix.

So che questo non risponde direttamente alla domanda ma, a mio avviso, fa parte dell'equazione. Nel complesso, tuttavia, penso che lo slancio e i processi di pensiero fortemente radicati a supporto dei database delle relazioni rendano difficile il passaggio delle persone. Attualmente la professione di DB è addestrata quasi esclusivamente nella teoria relazionale, rendendo i tuoi professionisti della DB molto interessati a evitare OODB e il mondo accademico insegna teoria della DB per i professionisti quasi esclusivamente sulla relazione.

Fino a quando i grandi DBA aziendali, i professori e il curriculum mainstream e la presentazione di personale oltre gli sviluppatori pronti a gestire OODB ritengo che sia improbabile vedere un appello di massa, non importa quanto sia buono dal lato dello sviluppo.

Answer 5

Beh, è ??strano vero? C'è una tale spinta verso la progettazione guidata dal dominio come l'apice dell'analisi e della progettazione orientate agli oggetti, e ci sono modelli aziendali là fuori per sfruttare i sistemi ORM per perseverare i nostri oggetti. Per me ha perfettamente senso che se il DESIGN dell'applicazione è orientato agli oggetti e focalizzato sul dominio, un OODB gioverà molto alla tua applicazione.

A parte le questioni relative alla maturità e alla diffusione, da un punto di vista filosofico un OODB sembrerebbe utile o un'applicazione OO. non dover mantenere quel livello di mappatura per cominciare;)

Ma guarda, se non stai progettando un'unità di dominio e usi oggetti come oggetti dati e ti piacciono i tuoi proc memorizzati, allora non lo otterrai davvero;)

Answer 6

Gli RDBM sono (costruiti su una solida base teorica, sono stati sul mercato per un tempo molto più lungo, possono modellare i dati più fedelmente degli OODB in molti casi, possono essere utilizzati da più DBA rispetto agli OODB). Questa è una ragione sotto forma di una tupla relazionale.

Answer 7

Se posso amplificare il punto di Phil: la standardizzazione di SQL. Gli OODB hanno provato linguaggi di query come OQL ma non sembravano mai seguire un vero standard. Anche la qualità dei linguaggi di query era sospetta, probabilmente a causa della mancanza di standardizzazione. Gli standard favoriscono la concorrenza, che genera qualità.

Answer 8

Uno dei motivi è che i database riguardano i dati e gli oggetti riguardano strutture e algoritmi. Dopo aver preso i dati e averli incorporati in classi, si caratterizzano le relazioni e le operazioni in una struttura statica. I database, d'altra parte, riguardano la destrutturazione dei dati in un mucchio di istanze di tabelle atomiche che possono essere riassemblate in strutture diverse (di solito con classi) senza disturbare l'integrità degli atomi.

I database sono in qualche modo analoghi agli hexahexaflexagons.

Answer 9

Quello e o / r-mapper. Attraverso di essi, la differenza rispetto ai veri OO-DB diventa molto più piccola, mentre i vantaggi di cui sopra rimangono validi.

Answer 10

Decisioni tecnologiche costose non vengono prese da persone con conoscenze tecniche. Le aziende che utilizzano database relazionali assumono molte persone che si sentono minacciate dagli OODB e quindi eviteranno di conoscerle.

Answer 11

Penso che ci siano due ragioni filosofiche.

In primo luogo, le persone tendono tradizionalmente a separare la persistenza dalla reale funzionalità. Dopo aver rimosso la "vita" di un oggetto lontano da esso e tenerlo principalmente per la persistenza, diventa un record, e quindi c'è la tendenza a trattarlo come un "senza vita". oggetto dati.

In seguito a ciò, quando le persone pensano a una vasta collezione di cose molto simili, iniziano a pensarle come tavoli piuttosto che come oggetti.

Penso che con O / R la distinzione stia iniziando a scomparire. Ad esempio, utilizzo l'ibernazione per scaricare gerarchie di classi davvero complesse in un database MySQL. Tuttavia, non scrivo materiale critico per le prestazioni del mio progetto, quindi sono sicuro che non sia stato fatto in modo efficiente.

Answer 12

Il motivo della lenta adozione di OODB si basa in gran parte su alcuni fattori chiave che rendono i database SQL relazionali più popolari e / o più appropriati. Mentre i database puramente orientati agli oggetti sono ora in uno stato in cui superano gran parte degli svantaggi del modello relazionale, mancano alcuni elementi chiave.

Per uno, tendono a mancare di supporto per la gestione centralizzata del database, anche se questo viene rapidamente corretto in vari prodotti.

Un secondo motivo è che pochissimi sistemi implementano un linguaggio di query standard e si affidano invece al linguaggio di programmazione o ai linguaggi di query specializzati per recuperare e manipolare i dati in archivio. Questo è un punto fermo per molti se devono imparare un nuovo linguaggio di query oltre alla mentalità totalmente diversa di un programmatore utilizzato per soluzioni basate su NoSQL. Inoltre, la maggior parte dei database basati su SQL / Relazionali ora supporta un po 'il design orientato agli oggetti, inoltre abbiamo wrapper come ORM che molti usano per "bypassare". i problemi dei database relazionali che non sono prontamente disponibili nel linguaggio di programmazione prescelto.

Ma questi problemi esistono principalmente negli ambienti aziendali. Come database incorporati in piccoli dispositivi, come archiviazione di siti Web e in settori come quello aerospaziale sono diventati molto popolari e in molti casi hanno completamente sostituito la necessità di database relazionali regolari.

Chi sa cosa riserva il futuro?

Answer 13

La serializzazione fornita dalla maggior parte del linguaggio consente di appiattire gli attributi degli oggetti e di memorizzarli facilmente nell'RDBMS e di recuperare in modo simile gli oggetti non è un grosso problema. La base ampia e solida manca ancora, il che ostacola l'utilizzo di OODBMS da implementare.

Attualmente sto pensando di fare questo come il mio progetto di tesi di laurea per fornire un framework generale per OODBMS che supporti quasi tutti i componenti che sono comunemente usati in un giorno RDBMS fornendo così un DBMS strutturato non lineare. Mentre studiavo mi sono imbattuto in un progetto chiamato db4o che è un approccio (implementato) all'utilizzo di OODBMS solo per Java e .net, quindi questo potrebbe essere un altro motivo di mancanza di generalità per tutti i tipi di piattaforme e lingue.

Answer 14

Penso che sia perché i grandi come Oracle avevano investito in database relazionali mentre il movimento orientato agli oggetti stava prendendo slancio ... potrebbe essere che diventeranno mainstream se Oracle / Microsoft investono in esso in grande stile ... il che sembra improbabile perché non hanno una forte ragione per farlo ... semplificherà la vita di molti programmatori ... ma "rendendo la vita dei programmatori più semplice" non è un ottimo obiettivo commerciale per loro!