Perché i database SQL sono ancora utilizzati con ORM?

La risposta presentata qui è una risposta rapida e non è completa, poiché l'argomento è piuttosto grande. La tua domanda riguarda 3 cose (almeno):

1- Database

2- SQL

3- ORM Concept

Un database è un qualsiasi repository di dati. Puoi memorizzare i tuoi dati ovunque sia appropriato per la tua applicazione. SQL è un modo per accedere a questi dati quando i dati di solito, SQL viene utilizzato per accedere e manipolare RDBMS. ORM rappresenta un modo per accedere ai dati dalle applicazioni utilizzando SQL o altri mezzi.

My question is: why are we even keeping SQL...

Se il tuo database non è un database relazionale o non è infetto da quali sistemi di database relazionali, potresti non dover utilizzare SQL. Negli ultimi 30 anni il database relazionale ha risposto a tante esigenze aziendali ed è diventato robusto, efficiente e affidabile. La forza concettuale ha mantenuto vivo questo sistema. È stato utilizzato in quasi tutti i tipi di applicazioni con grande successo. Gli sviluppatori hanno dimostrato che il concetto è possibile digerire e crescere abituati a questo standard specificamente per la programmazione procedurale. Come risultato di questa storia, i sistemi di database relazionali sono dove la maggior parte dei dati aziendali finisce per essere. Se stai costruendo un'applicazione che non ha bisogno di integrarsi con questi dati, sentiti libero di utilizzare un modello di database diverso.

Why doesn't the ORM just persist objects to XML or a binary file(s)?

Può funzionare per piccoli database quando non è richiesto l'accesso simultaneo ai dati. Un database relazionale consente l'accesso simultaneo ai dati, il blocco, l'indicizzazione (ricerca rapida), così come molte altre funzionalità che non sono nel file XML. Prendi il database degli account dei clienti della tua banca. Se vai a ritirare $ 20 dollari, il sistema dovrà cercare rapidamente il tuo account e trovarlo tra 4 milioni di account. Se provi a farlo in sequenza con un file, dovrai leggere circa ((4 milioni + 1) / 2) record prima di trovare una corrispondenza. Si tratta di molte letture. Inoltre, per aggiornare il tuo account dopo aver effettuato il prelievo, dovrai scrivere nuovamente l'intero 4 milioni di righe. Immagina che questo accada per ogni cliente, quindi immagina che questo accada su 300 teller allo stesso tempo.

Le seguenti potrebbero essere utili letture:

1- Componenti del database relazionale

2- Vantaggi del modello di dati relazionali (vedere la parte inferiore della pagina)

3- È il database relazionale destinato

Per i sistemi semplicistici, con esigenze di archiviazione dei dati molto semplici, ho spesso utilizzato un livello dati personalizzato che persisteva in XML. Tuttavia, per rispondere correttamente alla tua domanda, dovremo esaminarla dal punto di vista della maggior parte delle grandi aziende.

Why are we even keeping SQL and a SQL database as the back-end?

Una delle migliori risposte che posso darti è che i database tendono a sopravvivere ai sistemi che li utilizzano di gran lunga. I dati aziendali hanno un significato molto tempo dopo che la tecnologia del front-end è diventata obsoleta. Il codice di refactoring o riscrittura (un'attività non presa alla leggera quando si tratta di sistemi di grandi dimensioni) è molto più semplice del refactoring o della riprogettazione di un database. Oltre a non disporre degli strumenti e delle tecniche necessarie (TDD / refactoring automatico, ecc.), Quando si lavora con dati esistenti, ci sono molti altri fattori da considerare, come il tempo di inattività (cambiare le cose in un DB da 20 TB richiede un po 'di tempo ).

Inoltre - SQL, è un ottimo 4GL per l'accesso ai dati. Estrae gran parte della complessità e consente comunque prestazioni eccellenti (quando le cose sono fatte correttamente).

Why doesn't the ORM just persist objects to XML or a binary file(s)? Why bother with all the overheads and difficulties of administering a database server?

Se pensi a quello che stai dicendo per un minuto, ti renderai conto che stai descrivendo di nuovo un server di database. L'utilizzo effettivo dei database del meccanismo di archiviazione è un file binario altamente ottimizzato. Se non si utilizza un server DB, si finisce per reinventare gli indici e quindi reinventare le transazioni atomiche. Inoltre, se pensi che amministrare un DB sia un problema, probabilmente non hai provato ad amministrare milioni di file XML disparati.

Is this the way of the future?

Il mondo DB cambierà sicuramente molto nei prossimi anni, con "NoSQL" che mostra molti vantaggi. Tuttavia, la necessità di un modo maturo, affidabile per archiviare, recuperare e manipolare i dati non va da nessuna parte.

Perché li stiamo tenendo? Non posso parlare per te, ma ho bisogno di fare di più con i dati che semplicemente caricare e salvare oggetti isolati. I file XML non mi vanno molto bene se non c'è modo di cercarli ed eseguire calcoli rispetto ai dati che contengono diversi da aprire in sequenza ciascuno di essi. Come calcoli una ripartizione di, diciamo, vendite di questo anno per mese e prodotto, se tutti i tuoi dati sono distribuiti su milioni di piccoli file xml?

E, francamente, se pensi che la gestione di un server di database sia difficile, al confronto, provare a rintracciare milioni di file nel file system è un lotto più complesso!

Hai toccato qualcosa su cui si basa il movimento NoSQL, che la maggior parte dei sistemi (in particolare le applicazioni web semplici) di solito sono interessate a serializzare gli oggetti del loro modello di contenuto in un archivio di chiavi / valori e che molti dati gli scenari possono sacrificare la duplicazione dei dati per guadagni di prestazioni / semplificazione con l'indicizzazione semplice. Ciò significa che not significa che i database SQL (e l'ORM per parlare con loro) stanno comunque andando via. C'è ancora un grande bisogno di dati relazionali e di report su quei dati, di cui NoSQL non è una soluzione appropriata per.

Ti inviterei a controllare quanto segue:

• Wikipedia: NoSQL
• Wikipedia: coerenza finale
• Il database relazionale è destinato a fallire?
• Couch DB
• Mongo DB
• Raven DB

Il grosso problema è che gli oggetti OO presentano una visualizzazione strettamente gerarchica dei dati.

Prendi un tipico oggetto "Ordine" OO costituito da:

• Alcuni dettagli del cliente.
• Alcuni dettagli sulla consegna.
• Una raccolta di articoli dell'ordine
• Un codice prodotto.
• Una quantità.
• Un prezzo.
• Alcuni dati fiscali.
• Importo totale pagabile
• Alcuni dettagli di pagamento.

Questo è tutto buono e può essere mappato in sei o sette tabelle relazionali tramite l'ORM o un oggetto serializzato tramite un archivio oggetti, XML o file di testo normale.

Funziona bene per l'elaborazione degli ordini vanilla. Ma considera cosa succede quando l'acquisto vuole sapere quanti di questi prodotti sono stati ordinati oggi in modo che possano gestire il loro inventario.

• Con il back-end SQL possono attivare una semplice query SQL sulla tabella degli articoli e ottenere un totale per ogni prodotto nella sequenza ID prodotto.
• Con oggetti serializzati hanno bisogno di un programma personalizzato per leggere tutti gli ordini, scorrere ogni articolo dell'ordine, ordinare gli articoli nella sequenza corretta e riassumere le quantità.

In qualsiasi normale situazione di vendita, il marketing vorrà conoscere i volumi di vendita per prodotto, area e canale. Il magazzinaggio richiederà prodotti e quantità, i conti vorranno conoscere i prezzi e le tasse, il controllo del credito vorrà tracciare gli importi in sospeso da parte dei clienti ecc. Ecc.

Le basi di dati relazionali sono state progettate fin dall'inizio consentendo diverse viste sugli stessi dati. Basando le tabelle su un modello di Entity Relationship concepito che soddisfi le esigenze di tutti i potenziali utenti dei dati, viene creato un archivio dati efficiente e flessibile.

Con l'attuale serie di database OO è possibile progettare solo per una piccola serie di casi d'uso, altri potenziali usi sono esclusi.

Poco fa c'era una domanda simile e qualcuno ha postato questo link , che ho trovato abbastanza interessante. Personalmente, ho usato SQL diretto e pochi ORM e nel mio primo lavoro ho anche dedicato un po 'di tempo a ottimizzare le query SQL perché ciò che appare semplice sembra sempre interrompersi quando si inizia a lavorare con le righe 1M +. Anche se mi piace lavorare con gli ORM e credo che abbiano il loro posto, mi trovo a condividere molte visualizzazioni con l'autore di quel post.

Un ORM è un Object Relational Mapper, e poiché quasi tutti i database relazionali usano SQL non ci sarà molto di più di una modifica in quanto è la tua unica opzione.

Se dovessimo prendere in considerazione l'astrazione della persistenza e andare su quella strada piuttosto che sul concetto di ORM di alto livello allora sì, sarebbe bene avere un'astrazione di persistenza che ti permetta di salvare i tuoi oggetti / modelli in un determinato data store , che si tratti di MySQL, MongoDB, FlatFile ecc. Il problema è che i database relazionali supportano i dati relazionali, quindi puoi impostare le relazioni tra gli oggetti, tuttavia la maggior parte delle soluzioni basate su NoSQL si preoccupano più di perseguire l'oggetto nel suo complesso piuttosto che normalizzarlo in tabelle relazionali più piccole.

Ad ogni modo il punto principale da cui partire è che gli ORM sono stati progettati tenendo conto dei database SQL, la maggior parte dei database in stile NoSQL non usa relazioni (forse db grafico in un modo) quindi un ORM senza un database relazionale sarebbe ridondante.

if I am programming in a language, then I want to use the language's native implementation of objects and data structures to drive my program

si, esattamente questo. L'unico problema è quando si tratta di dati memorizzati in un database, l'implementazione nativa della lingua è SQL. Quindi tecnicamente se non stai usando SQL quando lavori con i database, lo stai facendo male.

Immagino che il problema qui sia che non si ottiene assistenza per gli strumenti come intellisense quando si incorpora SQL nel proprio codice. Il mio consiglio è quindi quello di utilizzare stored procedure, quindi il tuo SQL è racchiuso in una bella API che il DB ti espone (un po 'come implementare un servizio web). Quindi puoi utilizzare il tuo ORM come tecnologia di accesso client per chiamare questi sproc con l'ulteriore vantaggio di un migliore disaccoppiamento, maggiore sicurezza e prestazioni spesso migliori.