YAGNI si applica alla progettazione del database?

Question

Nel codice, è in genere abbastanza semplice aggiungere nuove classi per fornire funzionalità aggiuntive e così via. Ho una buona conoscenza del codice di refactoring e di ciò che è implicito, quindi YAGNI ha generalmente senso per me.

Ciò che non mi è familiare è l'utilizzo e l'aggiornamento di un database relazionale una volta distribuito. Sto sviluppando un piccolo progetto per animali domestici che sto pianificando di praticare Release Early, Release Often e mi chiedo se dovrei prendere in considerazione i dati che non verranno utilizzati nella versione iniziale, ma sono inclusi nell'elenco delle funzionalità pianificate? È facile aggiungere tabelle e modificare schemi così come aggiungere nuove classi? O dovrei provare ad avere tavoli per cose che potrei usare, ma che non prevediamo nell'immediato futuro?

Answer 1

Se si dispone di un buon test che colpisce il database, estenderei YAGNI alla progettazione del database.

In generale, è facile aggiungere colonne e tabelle e meno facilmente rimuoverle o modificarle in modo significativo. Prendilo in considerazione quando progetti tabelle (ad esempio se un cliente può avere più utenti, non aggiungere userid alla tabella dei tuoi clienti. Fai bene la prima volta).

Answer 2

La mia opinione è che YAGNI si applica a tutto, codifica, progettazione di database, lavoro in casa (mia moglie non è d'accordo con me con veemenza su questo), e così via.

Ogni applicazione basata su DBMS su cui abbia mai lavorato ha regolarmente aggiornato gli aggiornamenti su scema, pertanto è necessario pianificarlo nei processi. I DBA non apprezzeranno la parte "spesso rilasciata" della tua proposta, dal momento che questo è più utile per loro (o se si tratta di un database non DBA).

Ma questo è quello che sono lì per.

Answer 3

Questa è una domanda eccellente. Ho scoperto personalmente che la modifica di uno schema di database e la conversione di tutti i dati nella nuova rappresentazione sono molto più difficili del codice di refactoring. Tanto che, infatti, ogni volta che avvio un progetto che utilizzerà un nuovo database, mi prendo sempre del tempo prima di sedermi e scrivere qualsiasi codice per ottenere le mie specifiche il più approfondite possibile. Ciò che spesso comporta è anticipare le funzionalità e incorporare il supporto per loro nel database, anche se non ho intenzione di implementarle immediatamente.

Potrebbe essere un po 'più agile con il refactoring del database se si utilizza un framework o un altro livello simile che fornisce un meccanismo per alterare il database, ma se si scrive direttamente SQL, si consiglia di investire una quantità modesta di tempo per progettare e implementare uno schema che è meno probabile che richieda cambiamenti in futuro.

Answer 4

Il principio si applica ancora. Non dovrai preoccuparti di aggiungere campi alle tabelle ecc. Finché non avrai molti dati. Un sacco di dati. Quindi preoccuparsi troppo troppo presto dei dettagli dei piani di indicizzazione e di query senza vedere i dati effettivi spesso andrà perso tempo e porterà anche a problemi architettonici in seguito.

Sfortunatamente, il muck del design del database dopo un rilascio di produzione può essere piuttosto spaventoso se non viene seguito un buon processo di test/rilascio. Quindi, ancor più del codice, vuoi farlo bene la prima volta con un database.

Con i database, si desidera pianificare l'acquisizione dei dati oltre a inserirli e archiviarli, quindi se le funzionalità "pianificate" includono la segnalazione, ciò influenzerà molto la progettazione del database, quindi forse piano per quello.

Non è così facile modificare uno schema come aggiungere una classe, ma è fattibile.

Nel complesso, YAGNI si applica ancora.

Answer 5

Non impostare i tavoli che non sono ancora necessari. Parte del motivo dietro a YAGNI è che non prevedi in anticipo le cose giuste che ti serviranno. È possibile aggiungere facilmente nuove tabelle, modificare tabelle esistenti e così via quando è necessario cambiarle.

Un buon framework dovrebbe avere alcuni strumenti per eseguire migrations, che consentono di aggiornare e downgrade del database facilmente e automaticamente. Se hai questo posto, e sei ragionevolmente attento al tuo design, dovresti essere in grado di rifattorarti dove vuoi, piuttosto che cercare di trovare tutto ciò di cui avrai bisogno in anticipo.

Answer 6

Esiste tutta una serie di pensieri agili sulla progettazione e l'implementazione del database. Potresti essere interessato a guardare attraverso lo best practices allo www.agiledata.org per alcuni dei pensieri di Scott Ambler sull'argomento. Per quanto mi riguarda, in genere faccio crescere il design del database man mano che l'applicazione si sviluppa. Raramente creo tavoli in anticipo. Eccezioni a questo sarebbero cose come auditing e permessi, cose che attraversano l'intero progetto. Penserò a come implementare queste cose anche se in realtà non creo alcuna tabella per loro in anticipo. Gli aspetti trasversali influiscono sul design dei tavoli anche se quelle caratteristiche non sono sempre le prime fuori dal cancello.

Answer 7

Il design del database è come qualsiasi altro tipo di design. La tua comprensione cresce in modo incrementale e con una migliore comprensione arriva uno schema in evoluzione.

Vorrei che fosse più facile spiegare come esista, in effetti, una base concettuale per la progettazione dello schema del database relazionale. L'unico strumento che lo modella veramente è la modellazione dei ruoli degli oggetti, che è emersa da lungo tempo. Lo strumento più familiare era Visiomodeler. Per avere un'idea di questo, ecco un paio di link a Scott Ambler e Scot Becker Ma la conclusione che si potrebbe trarre è che le asserzioni del tipo di modellazione dell'oggetto conducono direttamente a un modello logico relazionale specifico; quindi lo schema dovrà cambiare come cambia il modello concettuale.

In pratica, il tuo rdbms può gestire un bel po 'di flessione se sei veramente a tuo agio con le espressioni di trasformazione; e ne vale la pena per essere bravo.

Nota: Penso che le tecniche di evitamento SQL come LINQ e Modelli relazionali oggetto costituiranno solo un ostacolo a un progetto in evoluzione. Potrei sbagliarmi. Ci sono alcuni motivi per sperare che l'Entity Framework di Microsoft comprenda la modellazione dei ruoli degli oggetti; ma ho visto solo riferimenti obliqui alla possibilità.

Answer 8

Esiste una base concettuale per la progettazione del database.

Nella progettazione di database classica, ci sono tre modelli: concettuale, logico e fisico.

Il modello concettuale emerge dall'analisi dei requisiti e si evolve man mano che l'argomento sottostante si evolve o quando la comprensione dell'argomento si evolve. Il modello concettuale appunta i dati elementari sulla forma e sulla semantica, ma non affronta questioni come la composizione delle tabelle.

Il modello logico utilizza il modello relazionale dei dati. Può essere derivato dal modello concettuale, ma si occupa anche della composizione delle relazioni. La normalizzazione e altri problemi di composizione entrano in gioco qui. Il modello logico anticipa la progettazione della tabella e anche le query e gli aggiornamenti che l'applicazione produrrà.

Il modello fisico implementa le relazioni come tabelle e aggiunge anche tutte le altre caratteristiche come indici, tablespace, ecc.necessario per costruire effettivamente il database. Deriva dal modello logico, ma tutti i volumi di dati, il carico, le prestazioni e lo spazio su disco entrano in gioco.

Questo suona lungo e noioso, ma in realtà è veloce, se sai come farlo. Il tutto può essere fatto in poche settimane, mentre il resto della squadra sta ancora discutendo le specifiche funzionali. Per un progetto veramente piccolo (6 tavoli, 50 colonne) può essere fatto in pochi giorni, con solo carta e matita. Per i progetti più grandi, esistono strumenti che rendono il design più automatico, meno soggetto a errori e facilmente diagrammato.

Ma cosa succede quando si scopre che il modello concettuale era inaccurato o incompleto e gli altri due modelli e il database stesso devono essere modificati? È qui che il Data Independence viene in soccorso. L'indipendenza dei dati fa per la progettazione del database ciò che l'incapsulamento fa per la progettazione dell'oggetto. Vale a dire, impedisce una piccola modifica in un punto dalla propagazione su tutti gli oggetti dell'applicazione. Gli oggetti dipendono solo dai dati che usano.

Se una nuova tabella deve essere aggiunta a uno schema, le probabilità che qualsiasi applicazione venga interrotta è estremamente piccola. Anche se una tabella esistente deve essere modificata, le query che utilizzano solo le vecchie colonne non vedranno alcuna differenza. Anche quando gli oggetti dipendono dal cambiamento, puoi sempre dare alla tabella modificata un nuovo nome e quindi creare una vista con il vecchio nome che faccia sembrare che la vecchia tabella sia ancora lì.

E l'indipendenza dei dati fisici è quasi completa in un buon DBMS. È possibile riorganizzare i dati, aggiungere e rilasciare indici, ecc. E non si dovrebbe dover modificare alcuna applicazione.

In breve, la gestione delle modifiche può essere eseguita in modo brillante utilizzando i buoni prodotti DBMS disponibili. Sfortunatamente, molti DBA e programmatori non sanno come fare un uso adeguato di queste funzionalità DBMS, anche se esistono da anni.