Esiste davvero un'asimmetria di impedenza relazionale all'oggetto?

Esiste sicuramente un'impedenza relazionale dell'oggetto. Ho dovuto occuparmene per anni su un prodotto che teneva i suoi dati su un database ma era OO quando funzionava.

Come esempio ampiamente semplificato, prendi in considerazione tre tabelle DB. Due sono solo elenchi, uno contenente persone e uno contenente lavori . Il terzo è un collegamento tra persone e lavori , con una colonna per ciascuno. (E tutti e tre hanno un sacco di colonne per molti dati sussidiari.)

Nell'interfaccia utente, un utente desidera esaminare i dati in termini di lavoro e le persone che ci lavorano. Uno sguardo al DB, se è grande, sarà inutile: troppe informazioni disorganizzate. Ma nell'interfaccia utente, un oggetto lavoro può fungere da base per una buona visualizzazione. Anche se l'utente ha una lista di un milione di lavori, può scorrere fino a quello che vuole e vedere tutte le informazioni rilevanti: chi ci sta lavorando e quando e quanto e con quali abilità, ecc.

Quindi sul DB ci sono 3 tabelle. Nel programma OO, hai oggetti job , persone e i loro collegamenti. Gli elenchi lavori e persone si riferiscono direttamente alle tabelle DB, ma non esiste un elenco di collegamenti . I collegamenti fanno parte o, in ogni caso, sono legati agli oggetti lavoro . Per creare una tabella di collegamento dai dati OO, devi lavorare attraverso tutti i lavori. Per creare un oggetto lavori appropriato, devi leggere la tabella dei link e fare qualche riorganizzazione dei dati.

Questa è l'essenza dell'impedenza. Questo esempio è semplice per essere facilmente compreso, ma sottovaluta drasticamente la difficoltà nel mondo reale di tradurre tra i due concetti.

OO è molto più veloce. È più facile usare una volta che è stato impostato . Tuttavia, forza una certa organizzazione sui dati. Se questa organizzazione non è fatta bene, o non è adeguata, ci possono essere problemi. Ad esempio, nel mio esempio l'oggetto chiave è il lavoro . Se vuoi sapere che lavoro sta facendo un individuo, non va bene. In questo esempio semplice , è ovvio che ci deve essere un oggetto persone che contenga tutto il lavoro che una persona sta facendo, ma in un sistema reale il numero di strutture possibili si avvicinerà all'infinito; devi scegliere di fare quel numero limitato che permetterà al programma di il suo lavoro.

Tornei OO quando l'aspetto di accesso casuale della memoria diventa lento. OO dipende da molti collegamenti diretti tra i bit di dati. Come dovrebbe funzionare un grande database OO? Un Database di documenti ha più senso, ma dovrà essere davvero un OO DB o duplicare grandi quantità di dati: si noti che un oggetto lavoro include oggetti persone e quelli Gli oggetti persone includono l'oggetto lavoro .

I dati relazionali sono molto più lenti, ma senza pregiudizi. Un po 'di SQL e puoi guardare i dati come preferisci. L'altro, travolgente, il vantaggio che ha è che la memoria lenta, non casuale, che porterà l'OO ad una battuta d'arresto, non lo infastidisce. Quindi, se hai terrabyte di dati, vuoi che i tuoi dati siano memorizzati in relazione, non orientati agli oggetti.

Quindi penso che siamo bloccati con database relazionali e programmi orientati agli oggetti e stiamo facendo un sacco di giri per ottenere dati dall'uno all'altra e viceversa.

Inoltre: ho recentemente lavorato su un sistema che utilizza dati relazionali in memoria. È molto lento, ma non così lento da essere seriamente fastidioso (non è un gioco per computer!) E gli sviluppatori originali, mentre dovevano progettare un DB, hanno dovuto saltare preoccuparsi di un design OO. Ho considerato OO un po ', ma ciò significava molta programmazione rispetto alla scrittura solo un po' di fantasia SQL (LINQ, in realtà). Mi ha fatto capire che a volte le relazioni possono competere con OO sul proprio terreno.

Sottolinea inoltre che OO forza l'organizzazione sui dati. Se gli sviluppatori originali avessero saputo cosa dovevo fare e usato OO per farlo, il programma sarebbe stato eseguito più velocemente e avrei potuto modificarlo con molto meno sforzo. (SQL è complicato.) Ma se non lo avessero fatto, il modo in cui avevo bisogno di farlo, sarei stato esattamente dove ero ma senza il DB relazionale in memoria.

Riepilogo: OO e relazionale sono due cose diverse e la conversione tra di loro implica l'impedenza: è un dolore. Ognuno ha i suoi usi, e penso che spesso saremo bloccati usando entrambi.

Penso No.

La mancata corrispondenza dell'impedenza non è un problema "Oggetti contro relazioni".

Gli argomenti di dettaglio possono essere trovati qui (file PDF, 11 / .pgs).

Un problema di mancata corrispondenza dell'impedenza tra applicazioni scritte in linguaggio OO e DB relazionale non è un problema di discrepanza tra approcci orientati agli oggetti e relazionali stessi. Le sue vere cause si possono trovare nell'implementazione abituale dell'approccio OO. Il confronto diretto tra i due approcci non può essere utilizzato come base per concludere che sono discrepanti o non corrispondenti. Viene inoltre presentata la prova sperimentale dell'assenza di contraddizione tra paradigma orientato agli oggetti e modello di dati relazionali.

Sì, esiste l'impedenza relazionale all'oggetto. Nei primi anni '80 e '90 pensavano che la soluzione sarebbe stata database di oggetti , il più famoso dei quali è probabilmente il Zope Object Database . Ora viene affrontato mostry con il software di mappatura relazionale degli oggetti .

L'esistenza di tutti questi prodotti dimostra che ci sono molti problemi da risolvere per far comunicare il mondo relazionale con quello orientato agli oggetti.

L'articolo wiki fornisce una panoramica ragionevole ma non necessariamente esperienza del mondo reale.

Le complessità di mappatura di un database relazionale a uno schema OO sono enormi e non esistono cose come "migliori".

Dipende da molte cose e di conseguenza finisco spesso per creare le mie implementazioni ORM. Un database di documenti è utile solo se il modello di accesso rispetta la struttura ad albero unidirezionale consentita da un database di documenti. Se hai bisogno di qualcos'altro, potresti trovarti ad avere bisogno di un database grafico che non si rivelerà migliore dei database relazionali per scenari di utilizzo tipici.

Mantenere i dati il più possibile normalizzati offre la massima flessibilità, ma non necessariamente le prestazioni. Personalmente, tendo a trovare i database dei documenti più utili come cache di risultati avanzati rispetto a qualsiasi altra cosa. Questo è un po 'fuorviante, perché se si desidera utilizzare i dati del documento in un modo diverso da quello del modello, anche se tutto è possibile, sarà molto più lento. Le prestazioni dipendono dai tuoi schemi di accesso e non esiste una soluzione "migliore". Vorrei raccomandare a chiunque di iniziare con un database relazionale poiché è probabile che soddisfi la maggior parte delle esigenze e dia la massima flessibilità. Aiuterà anche a fornire una misura dei modelli di accesso che renderà ragionevole qualsiasi scelta di utilizzare un database di documenti.

Penso che in realtà, a parte i problemi minori, è molto facile abbinare gli oggetti ai dati relazionali e viceversa. Questo presuppone che tu non stia utilizzando funzioni complicate come i trigger.

I veri problemi si verificano durante il runtime e nel flusso di dati. Hai problemi con coerenza, concorrenza, prestazioni, transazioni, ecc.

Ci sono due problemi difficili che ho sempre con ORM:

• Stai memorizzando i dati dal Database nella RAM, quindi c'è una discrepanza istantanea lì perché un altro processo può arrivare in background e cambiare qualcosa. Questo è in parte il motivo per cui anche i database degli oggetti sono difficili da usare. Certo, puoi bloccare le cose, ma se scruti sotto puoi vedere perché potrebbe non funzionare così bene.
• Le tue librerie stanno scrivendo la maggior parte degli SQL per te appena in tempo ma non hanno alcuna possibilità di essere in grado di ottimizzare il più possibile a mano. Questo è esattamente ciò di cui hai bisogno, basta prendere tutte le fermate per sicurezza. ORM non è in grado di prevedere esattamente ciò di cui hai bisogno, quindi devi calibrarlo attentamente o cercare di soddisfare ogni scenario. In breve, ORM è ingenuo.

Considera che hai una tabella con una colonna molto grande e un numero di colonne statistiche di base più piccole. La maggior parte delle volte non si desidera recuperare la colonna grande per le prestazioni. Qui è necessario trovare un modo per dire all'ORM di recuperare solo quella colonna su richiesta, nel qual caso si ha un potenziale problema di coerenza con i dati già acquisiti, si mantengono prestazioni scadenti, si rischia di dover bloccare in modo ingenuo, modificare lo schema per adattarlo meglio l'ORM con partizionamento verticale, ecc. Non è impossibile affrontare una delle centinaia di problemi, alcuni più difficili di altri. Il punto qui è che nel semplice vecchio SQL non dovresti pensarci due volte, otterresti ciò di cui hai bisogno quando hai bisogno senza dover anticipare e svelare l'ORM. La natura automatica di ORM lo rende molto più difficile da prevedere, soprattutto quando non esiste un modello ORM o un'implementazione, quindi devi imparare come funziona il tuo ORM sotto il cofano per usarlo veramente correttamente. Ci sono casi in cui gli ORM possono funzionare meglio ma in > Il 90% di questi casi è possibile ottenere lo stesso con una cache di query o qualcosa di semplice come in definitiva è ciò che ORM sta facendo in questi casi.

ORM è pensato per fare cose per te ma in realtà non può anticipare tutte le tue esigenze. Finisce per funzionare come riconoscimento della scrittura a mano su un touch screen dove metà del tempo invece di riconoscere la tua scrittura a mano, devi scrivere che può riconoscere (alcune lettere non funzioneranno a meno che tu non scriva a ritroso come e, ecc.). È molto comune che ORM sia vincolato a un layout di schema specifico che inizia con chiavi primarie per tutto (ma chi non lo fa comunque).

L'ho trovato personalmente, ciò che funziona meglio per me nella maggior parte dei casi è un sistema di modelli per ogni tabella che genera automaticamente le query ovvie che vengono ereditate per fornire query personalizzate per tutto ciò che ne ha bisogno e alcuni modelli separati da fornire categorizzazioni per evitare le classi di Dio o le domande fuori posto. Inoltre, mi piace solo utilizzare ORM per visualizzare i dati in cui la coerenza tende a non avere importanza, dal momento che verrà inviata a un client su cui non abbiamo alcun controllo e si tratta di un processo dell'ultima fase che si verifica dopo l'elaborazione quindi non interesserà direttamente le scritture.