La creazione e la cancellazione continue delle tabelle sono un segno di un difetto architettonico?

Sta diventando sempre più evidente a me ogni giorno che "agile" sta diventando sinonimo di scarsamente ponderata, caotica, frettolosa e con il sedile dei pantaloni. E nessuna di queste cose è compatibile con un approccio Agile come ho capito.

Avere un processo Agile efficace e ripetibile non è facile, e non credo che riduca intrinsecamente la quantità totale di lavoro da fare anche se potrebbe benissimo portare a prodotti migliori.

Se hanno affermato di non avere il tempo di "refactoring" il database, probabilmente non avranno nemmeno il tempo di impostare il controllo delle versioni e la migrazione per il database. Probabilmente non hanno avuto il tempo di creare una suite di test funzionali per questo. Tutte queste cose sono ciò a cui penso quando penso a un solido processo Agile che si sta dirigendo verso il successo.

Alla fine, Agile è solo una parola. Quello che stai facendo giorno per giorno determina se avrai successo o meno.

Anche se non è raro creare e rilasciare tabelle man mano che il design si evolve, potrebbe essere necessario eseguire alcune operazioni di pulizia per assicurarsi che il database stia davvero utilizzando tutte quelle tabelle.

Sì, Agile si occupa di refactoring, ma se ora stanno dicendo che il sistema è troppo grande per il refactoring, hanno smesso di fare Agile e ora sono solo programmazioni da Cowboy. Il team di sviluppo non vorrebbe essere chiamato così, ma è quello che stanno facendo. Guidare la gamma sparando a qualsiasi cosa si muova.

Un DBA ti aiuterà, assicurati solo di avere un DBA che comprenda lo sviluppo e lo sviluppo Agile. Il tuo team di sviluppo deve essere frenato, non gettato in prigione.

In generale, la creazione di nuove tabelle e l'aggiunta di nuove colonne spesso è normale in un processo in cui la programmazione e l'amministrazione del database non sono strettamente separate. Una nuova funzionalità potrebbe creare nuovi dati che devono andare da qualche parte. Prova troppo rigorosamente per evitarlo e finisci con un modello di piattaforma interna .

Il software ben scritto non rileva i nuovi oggetti del database, quindi non si interrompe nulla a causa di una nuova colonna in alcune tabelle.

D'altro canto, le colonne che cadono regolarmente o addirittura le tabelle sono sospette. Una nuova funzione non ha mai bisogno di una tabella rimossa, quindi questo potrebbe essere un segno di persone che lavorano completamente senza pianificazione.

Se il tuo database può essere facilmente versionato e migrato e hai i test per dimostrare che cambiare le cose non ha infranto le cose, probabilmente hai avviato un processo piuttosto agile.

Alla luce dei commenti - in genere l'effetto di questi è un gruppo di cowboy che si giustificano come urla agili. Veloce. E pubblica tutto ciò che puoi su thedailywtf.com in modo che tutti possano apprezzare il tuo horror.

Come la maggior parte delle risposte qui su StackExchange, la risposta dovrebbe essere "dipende". Nello sviluppo agile, i requisiti e le specifiche vengono scoperti durante l'implementazione.

Tuttavia, dato lo sviluppo agile, quando un modello relazionale è correttamente normalizzato, l'aggiunta di nuovi attributi alle relazioni dovrebbe essere raramente una necessità, le nuove entità dovrebbero generalmente riferirsi a quelle più vecchie, dato un modello appropriato.

La maggior parte degli sviluppatori non normalizza i propri DB a causa di vincoli temporali, pigrizia, incompetenza o complessità delle query. La rinormalizzazione richiede il trasferimento di dati esistenti, la modifica dei DAO, ecc. Ecc. Che genera un fattore di rischio.

Per rispondere alla tua domanda, no, non è normale in un processo Agile.

Dove sembrare può derivare da un atteggiamento Agile è il ciclo di progettazione / sviluppo / test di breve durata di Agile e l'enfasi di Agile sulle soluzioni leggere che soddisfano i requisiti noti, ma sono ben strutturate per essere in grado di soddisfare nuovi requisiti con un minimo cambiamento. Date queste due cose, si potrebbe dire che uno sviluppatore, non sapendo cosa potrebbe venire giù la linea, ma sapendo che la sua modifica non dovrebbe avere un impatto sul DB in un modo che non può essere annullato, apporta semplicemente le modifiche necessarie allo schema nel modo più "leggero" possibile, e poi ad intervalli diversi set di cambiamenti "leggeri" saranno rifattorizzati in qualcosa di più permanente e stabile.

Detto questo, non ho ancora lavorato con uno sviluppatore che si è iscritto alla teoria e alla metodologia Agile e ho anche pensato che creare e cancellare regolarmente tabelle nello schema fosse necessario per qualsiasi motivo. Agile non significa "schiaffo" o "bolt-on". Se ti viene fornita una storia che richiede l'aggiunta di un nuovo campo di dati appartenenti a un particolare record, aggiungi il campo alla tabella. Se quel cambiamento rompe qualcosa, capisci perché, e apporta altre modifiche che potrebbero essere necessarie (posso pensare a pochissime cose che si interromperanno aggiungendo una colonna a un DB interrogato, se si interrompe con questo tipo di cambiamento tu hanno problemi più grandi). Il refactoring è normalmente limitato al codice; la modifica dello schema è in genere un processo più complesso rispetto alla modifica del codice e, pertanto, quando devono verificarsi modifiche dello schema, di solito vengono eseguite con maggiore attenzione e almeno una certa attenzione alla conoscenza della direzione futura del progetto. Dovendo ri-strutturare alcuni o tutti i database indica un errore fondamentale del design; essere Agile non significa che non ci sia un "piano generale" di architettura di base e regole di progettazione da seguire mentre si costruisce organicamente il programma e la struttura dei dati.

Ora, ci sono casi in Agile dove ciò che "sai" ora sarà contraddetto da ciò che imparerai in seguito. Supponiamo che tu abbia il requisito che il tuo sistema debba avere un indirizzo per ogni persona. Poiché si tratta di una relazione 1: 1 e i dati saranno necessari nella maggior parte dei casi, è sufficiente aggiungere i campi Indirizzo alla tabella Persona. Una settimana dopo, si riceve il requisito che una persona possa avere più di un indirizzo. Ora è una relazione 1: N e per modellarla correttamente è necessario annullare le modifiche precedenti, suddividendo i campi in una nuova tabella di indirizzi. Questa non è una routine, specialmente tra gli sviluppatori senior. Uno sviluppatore esperto vedrà che una persona ha un indirizzo, considera questi come concettualmente separati e crea una tabella Persona e una tabella indirizzi, collegando Persona a indirizzo con un riferimento FK a un ID indirizzo. Uno schema come questo è più facile da cambiare se la natura della relazione cambia; senza creare o eliminare intere tabelle di dati "larghe", la relazione tra Persona e Indirizzo può essere facilmente modificata da 1: 1 a 1: N a N: N.

Quando lavoriamo con Agile, non c'è molta attenzione per il design in vista, quindi non vedo questo come un grosso problema, sicuramente per la prima versione.

È difficile commentare un sistema che ha 700 tabelle che non ho visto, potrebbe benissimo averli tutti, ma potrebbe anche accadere che il database non sia stato gestito abbastanza bene.

Anche in condizioni di agilità, per un grande sistema, è abbastanza comune avere ancora qualcuno / team responsabile dello schema.

Se stanno facendo frequentemente tali cambiamenti - in particolare facendo cadere tabelle e colonne in applicazioni live - sembra un segno di inesperienza. Non ha nulla a che fare con qualunque processo essi stiano affermando di seguire. 'Agile' non è una scusa per non sedersi e pensare sui dati che è necessario memorizzare e sul modo in cui si relaziona prima di iniziare a scrivere il codice. Se scoprono che stanno modificando più del 10-20% della struttura iniziale, per me è un indicatore che non stanno riflettendo o non hanno molta esperienza nell'analisi dei requisiti e nella progettazione di database, e quindi semplicemente ottengono troppo molto male all'inizio.

Anche se sembra che la tua squadra sia semplicemente codifica da cowboy, non ci dovrebbe essere nulla di sbagliato nel refactoring del codice O dei database. Non è un lavoro perso: si sta adattando a una realtà appena appresa.

Suggerirei di cosa ha bisogno la squadra è una sandbox per provare le modifiche, fare qualche test, rimuoverle dagli utenti e decidere se hanno senso. A quel punto, l'integrazione delle modifiche che hanno un senso - con adeguati test di regressione - nello schema dovrebbe andare bene.

Agile riguarda la codifica, i database non sono codice. Cambiare un database dovrebbe essere trattato come rimodellare una casa. La gente in qualche modo ha la convinzione che agile significa agire ora pianificare in seguito, che è completamente falso. Anche con metodi agili è necessario dedicare tempo alla pianificazione, soprattutto per qualcosa di importante come la progettazione del database.

Il mio ultimo lavoro è stato su una squadra come questa. Quando si utilizza un cambiamento di requisiti di processo agili. A volte le modifiche significano che un'entità esistente ha bisogno di un nuovo attributo risultante in una nuova colonna in una tabella esistente o se è necessaria una nuova entità risultante in una nuova tabella con relazioni alle tabelle esistenti. Questi tipi di cambiamenti arrivano con il territorio e non possono essere ignorati solo perché non vuoi toccare lo schema. Il successo è determinato mantenendo l'integrità dei dati durante la migrazione da una versione di database al successivo e corretto test delle unità.

Cerca semplicemente di non apportare modifiche non necessarie allo schema. Ad esempio, se una funzione richiede la creazione di una nuova tabella, assicurati di essere soddisfatto della definizione di tale tabella prima di eseguirne il check-in e distribuirla nell'ambiente di test. Dovendo annullare una modifica allo schema del database dopo che i dati sono stati migrati può essere doloroso.