L'unica soluzione che ho trovato è di avere uno strato funzionale tra il DB e l'applicazione. Le esigenze di dati nell'applicazione richiedono l'astrazione dallo schema DB e viceversa, per evitare che un cambio di schema diventi un intervento chirurgico massiccio. Questa non è la stessa cosa dell'utilizzo di un ORM.
Se lo schema DB deve essere modificato, la modifica deve essere accompagnata da cambiamenti nel livello di richiesta funzionale che estrae / spinga i dati. Allo stesso modo, le modifiche nella rappresentazione dei dati all'interno dell'applicazione devono essere accompagnate da cambiamenti nel livello dati che tira / spinge i dati.
Ciò che questo approccio aggiunge in termini di requisiti di codifica nel codice di chiamata all'astrazione dei dati che salva in enormi modifiche al tremolio del progetto da riscrivere al mondo. In particolare, impedisce a quei cambiamenti a livello di progetto di trasformarsi in funzionalità / creep e mettere la tua squadra in una situazione impossibile.
Un ulteriore vantaggio di questo approccio è che puoi implementare un tale livello ora e in incrementi senza diventare troppo selvaggio. Ad esempio, è possibile scrivere un livello di query tabella 1 per 1 che separa il codice chiamante dalla query DB e sostituire le precedenti query in-code (o chiamate di framework ORM o DB) con le chiamate a queste nuove funzioni che accettano e restituire esattamente qualunque cosa hai a che fare in questo momento. Questo è facile. Ora se hai bisogno di una modifica del DB, fallo con una modifica al codice del livello dati in modo che accetti e restituisca tutto ciò che fa ora, ma si occupa con garbo della modifica del DB. È quindi possibile modificare il codice chiamante stesso se questo ha senso.
A volte si scopre qualcosa di interessante sui dati non banali in questo processo - vale a dire che le traduzioni da oggetto a tabella sono non 1-per-1 e che la forma dei dati nel codice può non corrisponde mai alla sua forma in un DB relazionale, ma che un DB relazionale è il modo più ragionevole (a volte l'unico modo) per archiviare i dati se potrebbe mai servire direttamente più di una singola applicazione.