Perché i database di relazione sono più comuni dei database orientati agli oggetti?Perché OODBMS non è diffuso come RDBMS?
Se il paradigma di programmazione orientata agli oggetti è così diffuso, non dovremmo vedere molti OODBMS? Non avrebbero prestazioni migliori rispetto a RDBMS + OR/M?
Uno dei motivi per cui RDBMS ha mantenuto la popolarità è che ha una tecnologia consolidata, ben compresa e ha un linguaggio standard (SQL) supportato da più fornitori. Ha anche alcune buone interfacce come ODBC e JDBC che lo rendono abbastanza facile da connettere con linguaggi diversi. Un'API stabile è un fattore importante nel mantenere una tecnologia dominante.
Al contrario, non esiste un modello chiaro per OODBMS, né esiste un linguaggio standard, né esiste un'API standard. Non c'è nemmeno uno standard di fatto con un'implementazione leader del settore.
Il concetto OODBMS potrebbe eseguire meglio di RDBMS + ORM. Dipende interamente dall'implementazione. Ma è anche vero che OODBMS non risolve lo stesso insieme di problemi che RDBMS è in grado di risolvere. Alcune attività di gestione dei dati sono molto più semplici se si dispone di integrità referenziale e intestazioni relazionali applicate dalla soluzione di gestione dei dati. Queste caratteristiche sono assenti nel modello OODBMS (almeno finora).
C'è un sacco di rumore sui blog che i database relazionali sono obsoleti, ma RDBMS è tuttavia la migliore soluzione generica per la maggior parte delle attività di gestione dei dati.
penso che sia un caso di
Se non è rotto non cambiarlo.
I database relazionali sono estremamente radicati.
In una parola interoperabilità (parola grossa in una notte di Venerdì <G>)
maggior parte delle aziende devono lavorare con i sistemi legacy in esecuzione su RDBMS. Se dovessero utilizzare OODBMS, avrebbero comunque bisogno di accedere a RDBMS per determinate funzioni. È più semplice mantenere un unico modo di accedere ai dati rispetto a due.
Quando si hanno grandi nomi come Oracle e SQL Server nel mondo OODBMS e prestazioni comprovate in una varietà di ambienti, POI vedrete più progetti che li utilizzano.
I dati spesso vivono più a lungo ed è più importante del programma. Quindi, anche se inizi oggi uno sviluppo greenfield, devi considerare l'immagine complessiva. Ci sono più strumenti, processi e persone esperte che lavorano con i sistemi RDBM. Pensa al di là del programma, a proposito di pianificazione della capacità, data mining, reporting, ETL, integrazione con altre fonti di dati, ecc. Che ne dici della tua azienda che acquisisce un'altra società e quindi porta tutti i dati relazionali nel tuo programma. RDBMS e strumenti associati sono così radicati, provati e potenti che non ho alcun senso strategico nell'usare qualsiasi altra cosa. In qualche piccola nicchia forse ma non in generale.
"I dati spesso vivono più a lungo ed è più importante del programma." - Amen. I livelli intermedi vanno e vengono, ma i dati vivono per sempre. – duffymo
OODBMS non implica l'associazione a una lingua specifica più di quanto gli RDBMS siano associati alle stored procedure specifiche dell'implementazione. –
In teoria si è corretti ma in pratica ci sono alcune ben note implementazioni RDBMS e che sono ben supportate da strumenti, una vasta base di conoscenze e persone esperte. La mia azienda è appena passata a una fusione aziendale e abbiamo importato i dati dal database di altre società nel nostro database (con molte trasformazioni, masse di dati e pulizia). Entrambe le società hanno utilizzato Oracle e questo ha reso le cose più facili, certo che se l'altra azienda avesse utilizzato un database poco conosciuto. – softveda
I database di oggetti presentano una nicchia molto carina per problemi come la rappresentazione della geometria, ad es. Sistemi CAD, dove i grafici degli oggetti possono essere davvero molto profondi. Le prestazioni JOIN si degradano rapidamente per circa 7 tabelle nella maggior parte dei sistemi relazionali, quindi le strutture autoreferenziali in CAD hanno prestazioni migliori nei database degli oggetti.
Ma importanti applicazioni come i dati finanziari si prestano a una rappresentazione relazionale. Il modello relazionale ha una solida base matematica e SQL è un linguaggio popolare e di successo. C'è un piccolo incentivo per le istituzioni finanziarie come banche, intermediari e compagnie assicurative a passare da RDBMS.
Il problema più grande che ho riscontrato è la mancanza di standardizzazione. Nel mondo RDBMS, se si conosce SQL, è possibile ottenere molto lontano con qualsiasi database casuale. Fondamentalmente tutti lo implementano, con variazioni minori. Non conosco un singolo RDBMS esistente che non faccia SQL: puoi quasi usare "RDBMS" e "SQL" in modo intercambiabile.
La cosa più vicina a un OODBMS è forse OQL, che è stato un completo fallimento.
Nessun database ha mai implementato gran parte di esso. Ho usato un OODBMS commerciale abbastanza carino un paio di anni fa, ma (dal 2007 o giù di lì, ed era nella versione principale 8 o 9) non supportava nemmeno l'interrogazione di un oggetto con il suo nome. Il manuale diceva semplicemente che questa parte di OQL non era ancora arrivata. (Non sono sicuro, ma potresti essere stato in grado di entrare in una chiamata nativa per farlo.)
La maggior parte dei database di oggetti che ho visto di recente hanno interfacce in linguaggio nativo piuttosto che un linguaggio di query come OQL. Il sistema che ho usato, per esempio, supportava (solo!) Perl e VB, IIRC. Limitare il pubblico a solo un paio di lingue (o costringerlo a scrivere involucri, come abbiamo fatto noi) non è il modo di conquistare gli amici.
Per questo motivo, non c'è concorrenza, e quindi nessun piano di backup facile. Se metti i tuoi dati in MS-SQL e Microsoft smette di supportarli, puoi probabilmente scaricare i tuoi dati in Postgres e portare le tue query, senza troppi problemi. (Potrebbe essere un sacco di lavoro, se hai un sacco di domande, ma non dubito che potresti farlo. È un dolore, ma non tecnicamente impegnativo.) O Oracle, o MySQL, o molti altri, entrambi commerciali e libero.
Non esiste una cosa simile con un OODBMS: se quello che stai usando va a pancia in su, o lo portano in una direzione che non ti è utile, o trovi che manca una caratteristica chiave di cui hai bisogno, puoi semplicemente scaricare i tuoi dati in un OODBMS concorrente e portare le tue domande. Invece, stai parlando di cambiare una libreria di base e fare enormi cambiamenti di architettura. Quindi realisticamente, sei limitato a un OODBMS commerciale di cui ti fidi davvero (puoi nominarne anche uno?) O un OODBMS open source di cui ti fidi a mantenere il team quando le cose vanno male.
Se questo suona come FUD, scusa, non intendevo quello. Ma sono stato lì, e dal punto di vista della gestione del progetto ho esitato a tornare indietro, anche se l'ambiente di programmazione può essere meraviglioso. Un altro modo per pensarci è: guarda come è popolare la programmazione funzionale oggi, nonostante sia una buona idea. OODBMS sono così, ma peggio, dal momento che non è solo il tuo codice, ma il tuo codice e i tuoi dati. Sarei felice di iniziare un importante progetto a Erlang oggi, ma esiterei comunque a utilizzare un OODBMS.
venditori OODBMS: per modificare questo, è necessario make it easy to leave you for your competitors. Si può scavare OQL e implementarlo, oppure farlo a livello di API come ODBC, o qualsiasi altra cosa. Anche un formato di dump standard (usando JSON?) E strumenti per l'importazione/esportazione da/per quello per diversi OODBMS, sarebbe un ottimo inizio.
Per esempi trival OODB e RDB possono essere molto diversi. Soprattutto se si lavora con una quantità di dati abbastanza piccola da poter essere letti tutti in memoria in una volta sola e scriverli tutti contemporaneamente. Ma alla fine OODB ha bisogno di salvare i dati in un formato molto simile a RDB - non sono così diversi.
Considerare un grafico arbitrario di oggetti che potrebbero essere utilizzati in un'applicazione. Ogni oggetto può essere referenziato da diversi altri oggetti.Quando si salva un grafico di oggetti, non si desidera salvare gli oggetti ripetutamente ogni volta che vengono referenziati. Per prima cosa, se avessi un qualsiasi tipo di loop o riferimento automatico il tuo metodo save-object andrebbe in un loop infinito. Ma nel caso generale, è uno spreco di spazio. Invece, qualsiasi archivio di dati significativo deve dichiarare un identificativo univoco per ogni oggetto che viene archiviato (una chiave, solitamente una chiave surrogata in termini RDBMS). Ogni altro oggetto che fa riferimento a esso salva il tipo di oggetto e la chiave, non salva l'intero oggetto ripetutamente. Quindi qui abbiamo ricreato le chiavi esterne nel nostro object-store non RDB.
Quindi, fingiamo di voler memorizzare un elenco di oggetti (A1, A2, A3 ...) relativi a un altro oggetto (B). Abbiamo già stabilito che memorizzeremo le chiavi invece di salvare gli oggetti stessi due volte. Ma metti le chiavi sugli oggetti A1, A2, A3 ... sull'oggetto B, o metti la chiave sull'oggetto B su A? Se li immagazzini nel primo modo e hai tutte le A che vuoi, puoi afferrare rapidamente le B pertinenti. Il secondo modo è vero il contrario. Ma in entrambi i casi è un accordo a senso unico. Se si desidera eseguire una query sul retro di ciò che è stato archiviato e gli oggetti sono archiviati come XML o JSON, è un sacco di analisi inefficienti attraverso la maggior parte delle informazioni irrilevanti per trovare la chiave in ogni file. Non sarebbe meglio memorizzarli in un formato in cui ogni campo era separato, come le colonne in una tabella?
In una relazione molti-a-molti, o in un caso in cui è necessario trovare un gran numero di oggetti in entrambe le direzioni, questa strategia diventa molto inefficiente. L'unica soluzione performante consiste nel creare un oggetto helper per archiviare la relazione, con un file per ogni relazione in modo tale che il file sia costituito dalla chiave di A e dalla chiave di B in modo che possano essere cercati rapidamente. Abbiamo appena reinventato la tabella di riferimento incrociato.
Tabelle con colonne, identificatori univoci (chiavi), tabelle di riferimenti incrociati ... Queste sono le esigenze di base per la memorizzazione di oggetti in modo che possano essere recuperati in modo efficiente. Hmm ... sembra qualcosa di familiare? Un database relazionale fornisce esattamente questa funzionalità. Inoltre, più fornitori sono in concorrenza da decenni per fornire la più rapida archiviazione e recupero dei dati con i migliori strumenti per il backup, la replica, il clustering, l'interrogazione, ecc. Questo è molto per una nuova tecnologia con cui competere. E in definitiva sto dicendo che gli RDBMS sono fondamentalmente un'ottima soluzione al problema dell'efficiente archiviazione degli oggetti.
Ecco perché qualcosa come Hibernate esiste: per mettere un'interfaccia orientata agli oggetti su un efficiente sistema di archiviazione RDBMS. Dove vedete altri tipi di stoccaggio davvero brillare sono diverse problematiche:
Gli OODB non possono offrire prestazioni migliori degli RDB perché non sono fondamentalmente diversi.
Gli RDB sono qui per rimanere perché il salvataggio di grafici di grandi dimensioni in modo efficiente dal punto di vista dello spazio ed efficiente nel tempo sia per il salvataggio e il recupero, sia per la tolleranza agli errori e garantisce l'integrità dei dati è il problema per cui gli RDB sono stati progettati per risolvere in primo luogo. Questo è il motivo per cui anche JPA e Hibernate sono qui per rimanere - perché colmano il divario tra l'oggetto e i modelli relazionali dei dati. Modello a oggetti per facilità di manipolazione in memoria e relazionale per persistenza.
"Se non è rotto non cambiarlo" è così stupido ... perché sta facendo qualcosa di meglio, o lo sviluppo di un software più veloce è una cosa negativa. Il mio ultimo computer non era rotto quando l'ho cambiato, è stato solo LENTO !!!!Sforzarsi per soluzioni migliori e più efficienti è il mio obiettivo come sviluppatore. – billy