Come convincere qualcuno a normalizzare un database?

Question

Quindi ho lavorato a questo progetto al lavoro, dove sto codificando un sito Web php che interagisce con un database su cui non ho alcun controllo. Il database è stato "progettato" da un collega che è stato con la compagnia molti più anni che ho; quindi alla fine le decisioni sono lasciate a loro decidere.

Quando sono stato estratto a bordo di questo progetto sono andato a un collega e ho spiegato che lo schema del database sembrava imperfetto. Ho spiegato l'importanza di normalizzare il database per assicurare problemi di integrità dei dati, risparmi di spazio su disco e rendere più facile il lavoro del programmatore. Ho anche fornito esempi di come l'inserimento, la cancellazione e l'aggiornamento delle anomalie potrebbero verificarsi nel progetto corrente. Tuttavia il collaboratore mi ha spiegato che non volevano complicare eccessivamente il database del progetto e che non avrebbe cambiato il periodo.

Così ora sono un paio di mesi nel progetto e mi sto tirando i capelli ogni volta che devo unirmi a due tabelle per inserire un valore in un attributo che ha una relazione uno a uno con l'altro. (Quindi l'attributo dovrebbe essere stato appena un attributo della relazione principale.) Il database sembra orribile, e temo che anni in fondo questo mi ritorni da quando ho programmato il front-end che utilizza il database.

Qualcuno ha qualche suggerimento su come parlare di un collaboratore "superiore" nella progettazione corretta di un database? O qualche suggerimento su come evitare di frequentare anni frequentati per un progetto di cui non avevo nessuna parte? Dovrei semplicemente rifiutarmi di lavorare su progetti come questo in futuro? Lascia un commento nel mio codice dicendo che il database non stava facendo il mio?

Grazie.

Edit: Ulteriori informazioni in risposta ai commenti ...

so che la de-normalizzazione di un database può essere utile ai fini di velocità, quindi non mi si affaccia questo. Per coloro che leggono che non hanno sentito parlare di questa tattica illustrerò un esempio. Spesso i progettisti di database hanno una relazione di indirizzo che elenca la via, la città, lo stato e il codice postale dell'utente. Mentre tutti sanno che un codice postale determina la città e lo stato, costituendo quindi una tabella indicizzazione di codici postali per città e stati. Spesso i progettisti di database combinano le due tabelle, de-normalizzandole con lungimiranza che ogni query per l'indirizzo di un utente richiederebbe un join dalla tabella degli indirizzi allo zip table. Questo alla fine accelera il processo di interrogazione ed è un valido ragionamento per la de-normalizzazione di parti di un progetto di database.

Per inserire alcuni dettagli qui il database è progettato per un sistema Tour Request, quindi i dati all'interno sono correlati alle informazioni sui visitatori, alle date, ecc. Lo schema utilizzato dal database corrente è imprevedibile dall'inizio alla fine. Dalle incoerenze più semplici nei modelli di denominazione delle variabili (ad esempio num_of_visitors, arrivalMethod, ecc.) Per definire relazioni separate per un attributo one-to-one a stato singolo. Esempio: statusID rappresenta lo stato della richiesta di tour, può sempre avere uno solo stato valido selezionato da un gruppo di stati possibili (Approvato, negato, in sospeso, annullato). Per qualche motivo il database ha una tabella di stato contenente: tour_id (Primary chiave della relazione tour), statusID. Ciò consente di definire più stati per ogni richiesta di tour. Che, in base alla progettazione, una richiesta di tour dovrebbe essere in uno stato solo in un dato momento. Quindi è un difetto nel design, non una mia supervisione.

Answer 1

Dalla mia esperienza, purtroppo, questi tipi di situazioni spesso finiscono per essere battaglie inalienabili. Alcune cose che puoi fare per prendere le distanze dal progetto potrebbero essere:

• Implementare un livello di accesso ai dati nel codice che astrae il più possibile dal progetto di database effettivo. In questo modo, puoi strutturare il tuo codice in un formato migliore e "allontanarti" efficacemente dall'uso e dalla colpa per la cattiva progettazione del database.
• Creare viste nel DB per accedere ai dati in un formato più logico
• Fare piccoli refactoring alle tabelle/codice quando si ha la possibilità, se si può farla franca

non vorrei mettere commenti sprezzanti nel codice, perché molto probabilmente torneranno a perseguitarti. Nel tuo livello di accesso ai dati, potresti inserire commenti oggettivi/non offensivi che spiegano perché stai distruggendo un particolare progetto e come potrebbe essere progettato in modo diverso.

Se le cose vanno veramente male, e nessun altro ti sosterrà, potrebbe essere il momento di cercare un altro lavoro.

Answer 2

Cambia lavoro.

EDIT:

La risposta breve non è perché sto scherzando o non prendere sul serio la questione. Sono già stato in una situazione del genere. Il cattivo database non è il problema. Il problema è la gestione cieca o ignorante.Voglio dire che se non sanno o non si preoccupano che le decisioni tecniche importanti siano prese da persone incompetenti, allora le cose andranno peggio. È come camminare in una palude.

Considerare seriamente la ricerca di un nuovo lavoro. Ci sono davvero ottimi posti di lavoro per uno sviluppatore. Questo non lo è. Stai sprecando il tuo tempo.

Answer 3

Forse è possibile specificare le operazioni che è necessario eseguire su questo database e suggerire che le implementa come stored procedure nel database? ... Definirebbe sicuramente il problema a cui appartiene ... con la persona che l'ha causato.

Answer 4

Il modo più positivo sarebbe quello di lavorare con il collega e cercare di evolvere ed educare il loro modo di pensare. Forse discutere degli errori che hai fatto in passato sarà un facile rompighiaccio e mostrargli le implicazioni di un sistema mal progettato.

Se non hai troppe esperienze negative passate per aiutarti, ti suggerirei di registrare per quanto tempo (tempo o denaro) specifiche attività/difetti si stanno portando a termine. È quindi possibile produrre statistiche, tutti i gestori amano un grafico, che si spera mostrino come nel tempo sia aumentato il tempo necessario per aggiungere funzionalità o risolvere i difetti.

Spero che questo aiuti.

Answer 5

Questa domanda può essere riformulata per includere qualsiasi progettazione e implementazione indipendentemente dal dominio del problema.

È una grande causa di frustrazione quando si entra in una situazione come questa. Fortunatamente non mi sono imbattuto in questi più di un paio di volte e sono stato in grado di evitare in gran parte le parti del SW che sono state colpite. O costruisci un middle-layer che ti permetta di usare un layout di database più sano.

Se il progettista senior e la direzione non si preoccupano/capiscono di solito non c'è molto da fare. È lo stesso ogni volta che viene richiesto un cambio per sw che è in circolazione da un po '. Ottenere le modifiche approvate dalle persone che hanno progettato il sistema in primo luogo è spesso impossibile per varie ragioni psicologiche, a meno che tu non sia il superiore e possa "forzare" il problema. E anche allora in alcuni casi potrebbe non essere fattibile (potresti finire per aver bisogno di troppe modifiche al tuo sw).

Una possibilità sarebbe, tuttavia, se si hanno problemi specifici come le prestazioni.Se riesci a dimostrare che un design db migliore risolverà questi problemi potresti fare qualche progresso.

Answer 6

Provare a nascondere un database mal progettato dietro un livello è solo un "hack" e IMO dovrebbe essere il piano B. Per il piano A, proverei a "inoltrare" a un livello superiore.

Come hai descritto, non hai l'autorità per influenzare la persona che incasina il database. Poi andrei dall'architetto (ammesso che ce ne sia uno) o dal project manager se non ci sono architetti.

È molto importante sostenere le tue argomentazioni con fatti ben documentati sull'impatto che il cattivo design ha già sul sistema che stai costruendo. Altri fatti potrebbero essere problemi noti per database mal progettati dalle comunità db specializzate.

Non ho abbastanza informazioni sulla vostra situazione, ma questo è quello che di solito cerco di fare di fronte a clienti che insistono su una soluzione tecnica mal progettata.

Answer 7

Spesso uno sviluppatore deve lavorare con un cliente che richiede cose assurde o deve mantenere/lavorare con un codice legacy che è mal progettato. Ovviamente dovresti cercare di convincere/istruire i tuoi colleghi su come dovrebbe essere progettato un database, ma il tuo sforzo principale dovrebbe essere quello di fornire il codice sorgente della migliore qualità. Più spesso, bisogna affrontare situazioni del genere.

Raccomanderei di seguire un consiglio già dato per creare un livello attorno al database. Riempi con commenti come "Fare questa cosa complicata perché le tabelle 1 e 2 di db non sono normalizzate". Non criticare nei tuoi commenti. Tenerli rigorosamente tecnici. Di tanto in tanto discutete con i vostri colleghi/manager sulla progettazione del database. Compra un libro correlato e mettilo da qualche parte per tutti. Quando qualcuno chiede, offri di prestarlo. Tuttavia, i tuoi sforzi principali dovrebbero essere scrivere un buon codice.

Answer 8

Portali nel seminterrato. Offri loro una scelta tra portare un grande divano o 4 sedie piccole :)

Answer 9

Quando dice che non vuole complicare eccessivamente il database, forse intende dire che non sa o non è competente nella normalizzazione dei database . In tal caso, un modo sarebbe cercare di convincerla dei benefici della normalizzazione e di mandarla a studiare la normalizzazione del database. Una ragione per normalizzare sarebbe che la sola creazione di un database non è l'unico requisito per un database. Il database esiste perché viene utilizzato come archivio dati. E cosa memorizza i dati? Il software applicativo. Quindi il creatore del database dovrebbe onorare lo sviluppatore del software così tanto da normalizzare il database. Altrimenti sarebbe una situazione davvero imbarazzante. Per semplificare le cose, all'inizio potresti mostrare alcune operazioni di normalizzazione più semplici per iniziare.

Answer 10

Potrebbe non essere possibile convincere il progettista del database a rielaborare il database, specialmente se esiste già un sacco di codice scritto contro il database così com'è ora.

Tuttavia, è necessario espandere il proprio vocabolario per descrivere la differenza tra un database ben progettato e uno mal progettato. Esistono molti progetti di database non validi che non possono essere risolti semplicemente normalizzandoli. L'esempio che si dà è strappare i capelli perché è necessario unire i dati da tabelle separate quando un buon progetto avrebbe inserito i dati nella stessa tabella.

Scomporre una tabella che dovrebbe essere stata lasciata composta in genere non è un errore di normalizzazione. Quasi tutti i fallimenti di normalizzare risultano in tabelle composte che avrebbero dovuto essere scomposte. dai tuoi commenti su come istruirla su anomalie di aggiornamento, sono abbastanza sicuro che tu sappia già tutto ciò che potrei essere in grado di insegnarti sulle forme normali.

Le tabelle di scomposizione per cattive ragioni, talvolta denominate "ipernormalizzate", sono un altro aspetto del difetto di progettazione. I problemi di programmazione che sorgono da questo difetto sono molto diversi da quelli che derivano da sottotormalizzazione.

Quanti altri programmatori sviluppano codice che funziona sullo stesso database? Come si sentono gli altri programmatori riguardo al design? Se sono davvero felici, questo riduce ulteriormente le possibilità di cambiare le cose. Se sono tutti deformati, potresti persuadere il designer a trovare forza nei numeri. Lo so, lo so, è politica, e scommetto che odi la politica.

Indietro quando insegnavo ai programmatori sulla programmazione e la progettazione di database, gli studenti chiedevano spesso perché c'era così tanta politica nel lavoro di database. Alla fine ho trovato una semplice risposta:

Quando un database è ampiamente utilizzato, avviene la condivisione dei dati. Ciò implica la condivisione delle conoscenze. Sapere è potere. Quando il potere viene condiviso, la politica accade.

Answer 11

Trova un errore causato dalla denormalizzazione. Se il database non ha vincoli adeguati (e suppongo che non lo farà nelle circostanze), un tale errore sarà. Ci metterei dei soldi. Se stai usando un bug tracker, guarda lì. Se no, risolvilo da solo. In ogni caso, puoi dimostrare quanti danni possono causare tali errori e quanto costano da pulire.

Answer 12

Mostrare questa domanda all'alta dirigenza. Ciò mostrerà loro che la normalizzazione in una forma o nell'altra non è solo una "complicazione" di un database, ma una procedura standard che la stragrande maggioranza degli sviluppatori competenti considera fondamentale.