Possono le solite soluzioni ORM interagire con i database OO?

Question

Per esempio, può Hibernate maniglia CouchDB?

Che dire di supporto per altri database OO in altre soluzioni ORM?

Uno dei (non è così importante) i benefici di una soluzione ORM è la possibile capacità di scambiare un fornitore di database per un altro. Che cosa succede se si scambia un database relazionale per un oggetto orientato uno?

Answer 1

  

Che cosa succede se si scambia un database relazionale per un oggetto orientato uno?

Credo che questo dovrebbe essere possibile con JDO. In realtà, nella mia memoria, JDO è stato elaborato e promosso dai fornitori OODMBS e vedo questo standard come una sorta di modo unificato per interagire con OODBMS (e il piano era in due fasi: in primo luogo, Gentile cliente, utilizzare il mio JDO implementazione per la persistenza e quindi Gentile cliente, sostituire il database Oracle / Sybase / Qualunque sia con il mio database Versant ).

Ma io non definirei JDO come un "ORM", è più uno standard di persistenza degli oggetti trasparenti (che può agire come strumento ORM quando il sistema di archiviazione è un relazionale - la R in ORM - database).

Answer 2

"Che cosa circa il supporto per altri database OO in altre soluzioni ORM?"

Object-Relational Mapping (ORM) è una soluzione a questo problema.

1. oggetti nel programma.

2. Un database relazionali.

A meno che non si dispone di entrambe le parti (Programma OO, di database relazionale) non è possibile utilizzare ORM, perché non si dispone di un problema.

Se sei programmi di scrittura C, non è possibile utilizzare ORM -. Non si ha nessun oggetti per mappare

Se non si utilizza un database relazionale, non è possibile utilizzare ORM -. Non si dispone di qualsiasi database relazionale per mappare

Non c'è bisogno di ORM con OODB. Non c'è nessun problema da risolvere.

Answer 3

La mia comprensione (soliti avvertimenti di "potrebbe essere sbagliato" qui) è che le soluzioni ORM non funzionano con i database Object Oriented, come i database OO eliminano la necessità per la soluzione ORM.

In generale, un ORM è utilizzato per aiuto astratto modello relazionale, e lontano estratto dalla logica del codice del disadattamento del modello relazionale al sistema orientato agli oggetti. Permette anche per l'utilizzo di database tradizionali che sono spesso necessari per i sistemi legacy di continuare a lavorare, ma ti dà la libertà di gestire le relazioni in un modo OO.

L'astrazione è il vero vantaggio, imo, di usare un ORM. Scambiare fornitori di database non è così facile come qualcuno vorrebbe fare fuori per essere, in particolare è che si sta passando da o verso un database come Oracle, dove ci sono un sacco di operazioni personalizzate e comportamenti personalizzati nei driver JDBC.

Un altro elemento alla tua domanda è che è improbabile che si vorrebbe utilizzare lo stesso modello di database di riferimento da un database relazionale per un database object-oriented. Vorrei pensare che un tale cambiamento di paradigma consiglio, se non richiedono, un ripensamento del comportamento logico e il collegamento del sistema di base sottostante.

Answer 4

La "R" in "ORM" sta per "relazionale", quindi non credo che si applicano a ODBMS a tutti.

Il punto di utilizzare un database ad oggetti è essere in grado di persistere oggetti . Se li avete, che cosa avete bisogno per la mappatura?

Penso che il tipo di scambio si sta parlando è compiuto avendo un'interfaccia di persistenza di quella agnostica implementazione. Se si può fare, è possibile scambiare i database relazionali e oggetto. Forse qualcosa di simile a questo:

package persistence;

import java.io.Serializable;
import java.util.List;

public interface GenericDao<T, K extends Serializable>
{
    T find(K id);
    List<T> find();
    List<T> find(T example);

    K save(T instance);
    void update(T instance);
    void delete(T instance);
}

Answer 5

Lavorare con JSON, a seconda della lingua, è più facile che lavorare con istanze di classe.

IMHO un ORM è un passo indietro rispetto usando solo oggetti di serializzazione JSON e spingendoli a qualsiasi database NoSQL che era abbastanza intelligente da usare JSON come il loro formato di memorizzazione.