Come è possibile modificare il database sottostante su un progetto significativo della vita reale?

Ho visto questo tipo di cambiamento solo una volta, da un database Access a un database SQL Server. Era quasi senza soluzione di continuità e ha prodotto benefici ben oltre lo sforzo richiesto per effettuare il cambiamento.

È più comune cambiare l'ORM piuttosto che il database. Se si sta modificando il database, gli ORM possono fornire una zona buffer, poiché molti utilizzano i driver per comunicare con il database, piuttosto che comunicare direttamente con il database. Se l'SQL è conforme ANSI, tale modifica può essere relativamente semplice, in quanto è sufficiente cambiare il driver.

Il problema più grande sorge quando viene utilizzato SQL specifico del fornitore. L'esca di prestazioni migliori spesso supera i vantaggi apparentemente intangibili di mantenere il tuo sistema ANSI SQL compatibile e, una volta che vai su quella strada, ti chiudi in quello specifico fornitore. Cambiare il database diventa molto più difficile perché devi quindi riscrivere tutte le query specifiche del fornitore.

L'ho fatto in un contesto di microservizi: per motivi di prestazioni il team ha deciso di scambiare un database NoSQL con un altro. Siamo stati in grado di eseguire questo cambiamento entro uno sprint di due settimane. Ciò era ampiamente possibile a causa della buona separazione delle preoccupazioni: il codice responsabile della memorizzazione e della lettura dei dati era ben separato dalla logica aziendale, avevamo classi separate per oggetti business e persistenza / DAO, ecc. Un altro fattore era che il DB era usato solo per l'archiviazione e la lettura di voci basate su alcuni criteri semplici e non abbiamo dovuto utilizzare funzionalità molto avanzate che tendono a differire maggiormente tra i database rispetto alle operazioni di base di query / inserimento. E ovviamente non avevamo alcuna stored procedure.

D'altra parte, ho visto sistemi con database molto grandi e complessi in cui il codice DB era sparpagliato attorno alla base di codice e che difficilmente immagino di essere in grado di cambiare il motore DB in un breve periodo di tempo. Una possibilità per gestire una situazione del genere è cercare dati che sono per lo più indipendenti dagli altri. Tali frammenti potrebbero essere in grado di separare in un DB diverso e la migrazione passo a passo potrebbe diventare possibile. Ma certamente non sarebbe un compito semplice o che potrebbe essere fatto da un giorno all'altro.

Ci sono stato, fatto.

BTrieve - > Accesso - > Interbase - > Oracle nel corso di un singolo progetto.

I primi due solo durante la fase di prototipazione. Interbase è durato alcuni mesi nello sviluppo principale fino a quando non abbiamo raggiunto alcuni limiti importanti (20 anni fa potrebbe essere migliore ora), quindi siamo passati a Oracle. La transizione non è stata così dolorosa perché era all'inizio del progetto e la base di Inter non aveva molte cose proprietarie per intrappolarci (le stored procedure dovevano essere scritte come DLL). Inoltre, Oracle ha donato alcuni giorni di uno dei loro consulenti per aiutarci.

Anni dopo ho lavorato a un progetto di disattivazione del mainframe. DB2 - > Oracle, ma per lo più è stato riscritto principalmente.

I problemi principali che incontrerai saranno probabilmente più con le caratteristiche del database non SQL come le stored procedure che possono essere implementate in modo molto diverso da DB a DB. Prova a passare da PL-SQL a C # ... Rispetto a questo, la modifica della sintassi SQL e l'eliminazione di alcuni / RULE / commenti non è nulla.

Ritengo che tu presumi che non cambi i database a meno che tu non stia utilizzando qualcosa di sperimentale o non mainstream. La mancanza di esempi del mondo reale qui è una buona indicazione di quanto raro sia. Su questa base, prevedere qualcosa che potrebbe non accadere e paralizzare la tua applicazione nel processo non ha senso.

Approfitta di tutto ciò che il tuo database ti offre. Pianifica il database almeno a fondo come la tua applicazione. Probabilmente sopravviverà all'applicazione. Scopri come ottimizzare SQL e farlo quando necessario.

Ho visto un grande progetto del mondo reale che ha cercato di passare da un database Oracle a un database non relazionale di grandi dimensioni di IBM. Il progetto ha richiesto più di un anno, è andato pesantemente sul budget (stiamo parlando di milioni qui) e alla fine ha fallito.

What is it like to change the underlying database on a significant real-life project?

Dipende dal progetto.

La maggior parte delle applicazioni non ha il database al suo interno, l'applicazione ha solo bisogno di mantenere i dati. Viene scelto un database perché ... è ciò che fa un database. La scelta del database è la maggior parte del tempo basata sul prezzo / gratuito, esperienza del team con database precedenti, SQL vs NoSQL, ecc. Con questo tipo di applicazioni gli sviluppatori fanno un lavoro modesto di isolare il livello di persistenza e quindi le specifiche della perdita del database nell'applicazione. A seconda delle dimensioni della perdita, il passaggio a un altro database può richiedere settimane o mesi.

Poi ci sono applicazioni che isolano attentamente l'implementazione del database dal resto del codice. Molto tempo fa ho lavorato su un prodotto che poteva essere eseguito con qualsiasi database relazionale. Stavamo usando Hibernate e scrisse attentamente il codice per non dipendere da nessuna caratteristica specifica. Spesso abbiamo cambiato l'implementazione del database per ogni cliente. Oracle, MySQL, Postgres, non importava. Il cambio ha richiesto un paio d'ore.

E poi ho lavorato su app che erano solo strati sottili su un MS SQL Server. Il 99% della domanda era sotto forma di stored procedure. È ora di cambiare il motore del database? Anni!

Quindi dipende davvero. Se hai bisogno di cambiare il tuo database guarda la tua app specifica. Fai un'analisi approfondita, fai un preventivo e vedi a quale numero si finisce. Chiedere a sconosciuti su internet non ti aiuterà in questo caso:)