Sviluppo web - Oggetto DB vs DB relazionale

StackOverflow https://stackoverflow.com/questions/5358131

Domanda

Quali sono i contro e i professionisti dell'utilizzo di un database di oggetti o di un database relazionale per lo sviluppo web regolare che coinvolge molto CRUD?

AGGIORNAMENTO: ho riaperto la ricompensa di taglie per darla a Neville.

È stato utile?

Soluzione

Database relazionale:

Professionisti:

  • Tecnologia affermata: molti strumenti, sviluppatori, risorse
  • Ampia gamma di prodotti open source e commerciali
  • Noto per scalare a siti molto grandi e throughput molto elevato
  • Esprime molti domini problematici in modo logico e "programmabile"
  • Lingua abbastanza standard (SQL)

Contro:

  • La mancata corrispondenza dell'impedenza con i concetti OO - la modellazione di "eredità" in un database non è naturale
  • Le strutture gerarchiche di solito richiedono estensioni specifiche del fornitore alla lingua
  • I dati non relazionali (ad es. Documenti) non sono una vestibilità naturale
  • I cambiamenti nel settore aziendale possono essere difficili da implementare una volta che lo schema è stato definito

Oobdms

Professionisti:

  • Più vicino per i concetti OO
  • In teoria, uno sviluppatore deve solo lavorare in una lingua: i dettagli della persistenza sono astratti. Questo dovrebbe migliorare la produttività

Contro:

  • Significativamente meno strumenti/risorse/sviluppatori disponibili.
  • Nessun standard ampiamente accettato
  • L'approccio "Black Box" alla persistenza può rendere difficile la messa a punto delle prestazioni
  • I dettagli di persistenza spesso perdono nel design OO (vedi esempi di Marcelo)

Altri suggerimenti

Il concetto di OODBMS è piuttosto rotto e le varie offerte commerciali e gratuite emerse negli ultimi decenni hanno appena fatto un po 'sul mercato.

Il modello relazionale è più potente dei modelli di oggetti in termini di tipi di domande che puoi porre ai tuoi dati. Sfortunatamente, SQL ha eliminato gran parte del potere espressivo di cui è in grado il modello relazionale, ma anche in questa forma diluita, è ancora più facile esprimere query in SQL che in un tipico database OO (che sia ORM o OODBM).

Le query in un OODBMS sono prevalentemente guidate dagli operatori di navigazione, il che significa che se il tuo database di vendita ha le vendite che possiedono le loro vendite, quindi interrogare le vendite mensili per un determinato SKU non solo è probabile che sia paralizzante, ma molto imbarazzante da esprimere. Considera anche un modello di sicurezza che concede ai dipendenti l'accesso agli edifici. Qual è il modo corretto per esprimerlo? I dipendenti dovrebbero tenere una raccolta di edifici a cui possono accedere o gli edifici dovrebbero avere una raccolta di dipendenti che hanno accesso ad essi? Più precisamente, perché entrambe le classi dovrebbero avere una collezione dell'altra cotta nel suo design? E, qualunque tu scelga, come chiederesti a quali coppie di dipendenti hanno più di un edificio a cui possono accedere in comune? Non esiste un modello di navigazione semplice in grado di rispondere a tale domanda. La soluzione ragionevole-un oggetto "accesso"-è essenzialmente una reversione a uno schema relazionale correttamente normalizzato e richiede una sorta di linguaggio di query che prende in prestito pesantemente dall'algebra relazionale per rispondere alla domanda senza un enorme esagerazione Trasferimento di dati di filo.

Considera anche un'altra grande forza propagandata per gli OODBM: metodi, in particolare l'eredità con i metodi virtuali. Una clinica sportiva potrebbe avere diverse metriche a rischio per diversi tipi di atleta. Nel mondo ORM, questo verrebbe automaticamente espresso come una gerarchia di classe, con Athlete alla radice e un metodo virtuale, int InjuryRiskScore() implementato da ogni classe derivata. Il problema è che questo metodo è invariabilmente implementato sul cliente, non sul back -end, quindi se si desidera trovare i 10 atleti a rischio più alto in tutti gli sport nella tua clinica, l'unico modo per farlo è prendere tutti gli atleti attraverso il filo e passarli attraverso una coda prioritaria sul lato client. Non conosco anche il mondo OODBMS, ma penso che si verifichi lo stesso problema, poiché i motori di archiviazione generalmente memorizzano solo dati sufficienti per reidratare gli oggetti nel linguaggio di programmazione del cliente. Nel modello relazionale o SQL, esprimerebbe il punteggio del rischio di infortunio come un punto di vista, che potrebbe essere semplicemente l'unione delle opinioni di tipo atleta. Quindi, fai solo la domanda. Oppure puoi porre domande più complicate come "Chi ha avuto il maggiore aumento del loro rischio di violazione dal controllo del mese scorso?" Oppure, "quale punteggio di rischio si è dimostrato il miglior predittore di lesioni nell'ultimo anno?". Ancora più importante, queste domande possono essere risposte a tutti all'interno del DBMS con nient'altro che la domanda e la risposta che viaggiano attraverso il filo.

Il modello relazionale consente al DBMS di esprimere le conoscenze in modo altamente distillato in base alla logica predicata, che consente alle varie dimensioni dei fatti che si archiviano di essere uniti, proiettati, filtrati, raggruppati, riassunti e altrimenti riorganizzati in un ad hoc completamente ad hoc maniera. Ti consente di cucinare facilmente i dati in modi che non erano previsti quando il sistema era stato originariamente progettato. Il modello relazionale consente quindi la più pura espressione della conoscenza che conosciamo. In breve, il modello relazionale contiene fatti puri - niente di più, niente di meno (e certamente non oggetti o proxy).

Su una nota storica, il modello relazionale è emerso in risposta a uno stato disastroso con la rete esistente e i DBMs gerarchici dell'epoca, e in gran parte (e giustamente) li ha spostati per tutte tranne una piccola nicchia di applicazione (e anche queste probabilmente (e anche queste probabilmente (e anche queste probabilmente (e anche queste probabilmente (e anche queste (e anche queste probabilmente è rimasto in gran parte perché SQL non è riuscito a consegnare la potenza RMS). È profondamente ironico che gran parte dell'industria ora sta essenzialmente desiderando i "bei vecchi tempi" dei database teorici di rete, che sono essenzialmente ciò che gli OODBMS e l'attuale raccolto di database NoSQL stanno tornando indietro. Questi sforzi criticano giustamente SQL per la sua incapacità di soddisfare le esigenze di oggi, ma sfortunatamente hanno assunto (erroneamente e probabilmente per pura ignoranza) che SQL è un'espressione ad alta fedeltà del modello relazionale. Quindi hanno trascurato di considerare persino il modello relazionale stesso, che non ha praticamente nessuna delle limitazioni che ha allontanato così tanti da SQL, spesso verso OODBMS.

Posso rispondere alla tua domanda rispetto a un database di oggetti che conosco bene: ZodB.

Lo ZODB ti consente di persistere in modo quasi completamente in modo completamente in modo trasparente. Il suo utilizzo equivale a qualcosa di simile:

 # 'Persistent' allows us to save things transparently
 class Car(Persistent):
   def set_wheels(number)
      self.wheels = number

 # 'database' is a ZODB database
 database.car = Car()
 database.car.set_wheels(3)

Dovrai guardare molto tempo per trovare quel tipo di leggibilità con un RDMBS. Che esiste il Big Pro nell'utilizzo di ZODB in un'applicazione Web.

Il grande aspetto negativo, come delinea Marcello, è la mancanza di potenti domande. Questo è in parte un effetto collaterale della comodità del linguaggio sopra. Quanto segue è completamente OK e tutto sarà persistito nel database:

 database.car.colour = "yellow"
 database.car.owner = "Trotter"
 database.car.neighbour = Car()

Tuttavia, questo tipo di flessibilità rende difficile ottimizzare query complesse su diversi modelli. Basta fare un elenco di tutte le auto gialle con i vicini O(n) tempo a meno che non tiri il tuo indice.

Quindi, dipende da cosa intendi per "sviluppo web regolare". Molti siti Web non richiedono in realtà query multidimensionali complesse e le ricerche in tempo lineare non sono affatto problemi. In quei casi, l'uso di un RDBMS può a mio avviso a comparire eccessivamente il tuo codice. Ho scritto molte applicazioni di tipo CMS utilizzando esclusivamente un database di oggetti. Un sacco di Crud non ne entra in particolare; ZODB è molto maturo e scale e cache abbastanza bene.

Tuttavia, se stai scrivendo un'applicazione Web che deve fare complessi rapporti aziendali sulla falsariga di Google Analytics o una sorta di sistema di gestione delle inventari del magazzino con molti terabyte di dati, allora sicuramente vorrai un RDBMS.

Per riassumere, un database di oggetti può darti la leggibilità e manutenibilità a costo delle prestazioni complesse di query. Naturalmente, la leggibilità è una questione di opinione e non puoi ignorare il fatto che molti più sviluppatori conoscono SQL rispetto ai vari dialetti di database degli oggetti.

Nel normale sviluppo web uso il mare su gemme. Per la maggior parte delle applicazioni, ciò significa che scrivo zero codice di connessione del database. Si comporta, scale, lo sviluppo è circa cinque volte più veloce.

L'unica volta che userò mai di nuovo un database relazionale per lo sviluppo web è quando devo connettermi a uno esistente.

I vantaggi:

  • Meno codice, sviluppo più veloce;
  • Scalabilità molto migliore;
  • può gestire modelli molto più complessi;
  • Agilità del progetto molto migliore;
  • Ho menzionato flessibilità;
  • è possibile gestire le modifiche nei modelli di classe, non solo ai dati ma anche al codice;

Gli sgradevoli:

  • Probabilmente dovrai formare gli sviluppatori da soli;
  • Quello che desideri (pietra preziosa) costa denaro serio per sistemi di grandi dimensioni

Relazionale db

  • SQL e standard
  • facile da modellare
  • può utilizzare solo tipi standard e fornitori
  • Integrità referenziale (matematicamente solida teoria degli insiemi relazionali)
  • molti strumenti e implementazioni di database
  • Dati separati dal programma
  • Gestione dello stoccaggio e supporto infrastrutturale di fascia alta
  • Gestione delle transazioni e della concorrenza eseguita all'interno
  • Il modello relazionale è basato sul valore Le righe sono identificate dalle chiavi primarie

Contro

  • Nessun tipo personalizzato
  • Nessun tipo di dati estensibili
  • errore di impedenza
  • Impossibile esprimere una relazione nidificata
  • non può utilizzare entità complesse come singola unità
  • È necessario definire le chiavi e vari tipi di relazioni a livello di modello di dati
  • scrivere procedure per versioni, transazioni se necessario

Oggetto DB

  • Alte prestazioni
  • Più veloce come non richiesto
  • Meccanismo di versioning intrinseco
  • Interfaccia di navigazione per operazioni (come il grafico)
  • Linguaggio di query oggetto recuperare gli oggetti in modo dichiarativo
  • Tipi di dati complessi
  • Identità dell'oggetto IE. equals () in cui l'identità dell'oggetto è indipendente dal valore e dagli aggiornamenti
  • Facilita la condivisione degli oggetti
  • Classi e gerarchie (eredità e incapsulamento)
  • supporto per le relazioni
  • integrato con un linguaggio di persistenza come ODL
  • supporto per l'atomicità
  • Supporto per le relazioni nidificate
  • Modellazione semantica

Contro

  • Nessuna base matematica come RDB (fare riferimento a CODD)
  • Contro dell'orientamento agli oggetti
  • Persistenza difficile per strutture complesse, alcuni dati devono essere transitori

Database oggetti-relazionali (Potresti aver visto UDTS!)

  • Supporto per tipi di dati complessi come raccolta, multiset
  • Modellazione dei dati orientata agli oggetti
  • SQL esteso e tipi ricchi
  • Supporto per l'ingresso UDT
  • Lingua di query potente

Possono essere necessari approcci diversi (OO, DB relazionale o OODB)

Riferimenti

Il vantaggio di utilizzare database relazionali per grandi corpora

Database relazionale del database relazionale

Manifesto Oodms

ODMG

Vantaggi di un database relazionale

Il manifesto del sistema di database orientato agli oggetti

Sistemi di database orientati agli oggetti

Database relazionali di oggetto in DBMS

Criteri di completezza per i sistemi di database degli oggetti-relazionali

Confronti

http://en.wikipedia.org/wiki/comparison_of_relational_database_management_systems

http://en.wikipedia.org/wiki/comparison_of_object_database_management_systems

http://en.wikipedia.org/wiki/comparison_of_object-relational_database_management_systems

Penso che tutto dipenda dalle specifiche del tuo problema. (Sto davvero uscendo su un arto qui, lo so.)

Tutto ciò che sappiamo è che vuoi utilizzare il DB per lo sviluppo web e farai molte operazioni sui dati.

Una delle domande pertinenti da porsi è quanto sia importante che il DB sia strettamente integrato con gli oggetti che manipoli? Più è necessario, più un DB orientato agli oggetti si raccomanda.

D'altra parte, se i tuoi dati si prestano facilmente al modello relazionale, un DB relazionale potrebbe essere migliore.

Pensa alle operazioni che devi fare. Avrai bisogno di analisi di tutti i tipi di elementi con attributi diversi? Di quanto avrai bisogno per a prova di futuro il tuo DB?

Dovrei aggiungere che se è probabile che il tuo DB sia abbastanza piccolo, le prestazioni non saranno un grosso problema. Ma se la performance è, in effetti, un problema, hai molte cose di cui preoccuparti al di là di OO vs. Relazionale DBS. (Solo per scegliere un esempio dal mondo relazionale DB, quale modulo di normalizzazione dovresti usare? Questo è una domanda estremamente importante e complessa. Stai mantenendo un sistema operativo o un data warehouse? Sai in anticipo che alcune domande sono di fondamentale importanza o di trascurabile importanza? & c.)

Oltre alla questione delle prestazioni di DB e dell'integrazione con il tuo modello a oggetti, ci sono altre domande del mondo reale da porre. Hai limiti di dischi / server / larghezza di banda? Offrirai solo un numero limitato di operazioni agli utenti Web o potresti nemmeno creare le proprie domande/modifiche?

Per altre domande più importanti del mondo reale, con chi lavorerai? Cosa sanno già (o preferiscono)? E se non hai ancora conoscenza del dominio, forse hai una curiosità personale che ti spinge in una direzione? Se stai iniziando su un progetto personale, seguire le tue preferenze è una guida migliore al successo piuttosto che preoccuparti delle prestazioni prima ancora di iniziare.

Se puoi rispondere a queste e domande simili, anche se la risposta è "Non lo so", sarai in grado di ottenere una direzione molto migliore su come procedere.

In contratto con la risposta in profondità e ben ponderata di Marcelo, direi che, in base al fraseggio della tua domanda "Sviluppo web regolare", la mia risposta al polsino sarebbe quella di dire che saresti difficile trovare abbastanza professionisti Per giustificare l'uso di un oggetto DB su un DB relazionale tradizionale, per il semplice fatto che sono più risorse/sviluppatori/tutorial/ecc. che hanno più familiarità con il tradizionale modello relazionale e come utilizzarlo per ottenere "sviluppo web regolare".

Detto questo, penso che con alcuni degli ormi moderni ottieni un po 'del meglio di entrambi i mondi, in quanto i tuoi dati sottostanti siano archiviati in un RDBMS ben compreso (che è probabilmente stabile, supportato, ecc.) Ancora astrarre alcune delle capacità di modellazione di oggetti che possono (probabilmente) essere più adatte allo sviluppo di applicazioni CRUD.

Devo ammettere che non sono esperto nelle attuali capacità dei moderni OodBMS, tuttavia a meno che tu non sia in un campo che è completamente adatto a raggiungere una perfetta rappresentazione di oggetti del tuo dominio (e hai il talento di modellazione di oggetti per trarre vantaggio ), poi rimarrei con un RDBMS per il tuo spazio di archiviazione persistente.

Spero possa aiutare!

Questo spiega praticamente i pro e i contro:

http://en.wikipedia.org/wiki/object_database

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top