Sr. Dev ha creato un database con cui non sono d'accordo. Consulenza richiesta [chiusa]

2

Ho bisogno di correre al lavoro presto, quindi sarà breve.

Sono in compagnia solo da un paio di settimane. È una buona compagnia, questo è un appaltatore che ha il doppio dei miei anni. Sono nuovo nel campo della programmazione professionale.

Questo database fa esattamente ciò che Wikipedia dice di non fare per 1NF. Ripete colonne telefoniche in vari tavoli. Questo è uno sciopero.

Strike two: alcuni dati sono duplicati su tabelle. Flat out duplicato.

Colpo tre: non vitale, ma ha trasformato tutte le chiavi in bigints. Tutti i "FK_" sono anche annullabili. Wtf?

Non abbiamo ancora iniziato a utilizzare questo database, ma c'è stato un grosso crono per soddisfare le esigenze e la tempistica del cliente da quando sono entrato e la cronologia attuale la userà, ad esempio, domani.

Per me andava bene a sedermi mentre faceva casino perché non avevo a che fare direttamente con lui, ma sembra che prenderò in consegna questa sezione del codice mentre è necessario per l'architettura qualcos'altro .

Qualsiasi consiglio sarebbe molto apprezzato. Il mio capo è un grande uomo, ma è anche molto, molto impegnato e lo stress è l'ultima cosa di cui ha bisogno.

Aggiornamento:

Spiacente, questo è venuto fuori come un rant e meno di una domanda corretta. Apprezzo davvero tutte le risposte e mi hanno aiutato a iniziare a visualizzare il "problema" in modo più analitico. C'è anche qualche vantaggio per la loro generalizzazione in quanto lo stesso consiglio si applicherà ancora ai "problemi" futuri.

Grazie.

Secondo aggiornamento:

Quindi cercai gentilmente di capire perché ha fatto quello che ha fatto e per la maggior parte ha anche ammesso di non avere una buona ragione. Abbiamo finito per passare un po 'di tempo e tagliare quasi tutte le colonne duplicate. Per il resto delle stranezze, posso mordere la mia guancia abbastanza bene dal momento che sono solo fastidiosi e non potenzialmente distruggeranno se ogni campo duplicato non viene aggiornato. Tutto sommato una buona giornata.

PS Ho difficoltà a scegliere la migliore risposta dal momento che ce ne sono tanti buoni.

Aggiornamento: ottobre 2015 Solo per divertimento visto che è bello vedere quello che ho scritto quattro anni fa ... Lascio il resto invariato per preservare le sue qualità giovanili:)

Il senior in questione è stato licenziato nel giro di un paio di mesi e abbiamo finito per riscrivere il prodotto da zero mantenendo quasi nulla del codice o del database del ragazzo. Lui era "necessario altrove" era l'inizio di quella transizione. (A volte hai ragione ...)

Le risposte e i consigli forniti qui sono ancora molto validi: scopri perché qualcun altro ha fatto qualcosa prima di criticare. (... ea volte non lo sei.)

    
posta emragins 15.06.2011 - 16:21
fonte

9 risposte

15

"Per me andava bene sedermi mentre faceva casino perché non avevo avuto a che fare direttamente, ma sembra che prenderò questa sezione del codice mentre è necessario all'architettura qualcos'altro. "

Odio dirlo, ma se hai avuto l'opportunità di commentare quando, potresti aver appena colpito il momento dell'apprendimento in cui la triste verità è che nessuna area del codice è solo un problema di una persona. In una buona squadra, la gente DOVREBBE la transizione tra le aree, e ciò significa che l'incubo dell'altro ragazzo può diventare il tuo incubo molto rapidamente. La buona notizia è che il controllo ti dà l'opportunità di fare dei buoni cambiamenti.

Suggerirei i seguenti passaggi:

  • Parla con il ragazzo che l'ha progettato. Chiedi perché ha fatto quello che ha fatto - quale problema stava cercando di risolvere? Ha preso in considerazione altre opzioni? Impara i fattori trainanti alla ragione di queste decisioni.
  • Pensa se il design è così orribile - qual è l'impatto di lasciarlo da solo? Mentre può esserci un modo migliore, a volte i modi migliori non sono tanto una vittoria che hanno senso in un senso a breve termine. E se il tuo gruppo è in una fase di sviluppo o di rottura a breve termine, potrebbe essere necessario negoziare vincite a lungo termine come l'estensibilità con guadagni a breve termine per mantenere il progetto.
  • Se riesci a trovare un modo migliore per risolvere il problema, e questo codice è diventato un tuo problema, quindi proponi le correzioni. Se hai una relazione decente con il creatore, eseguili da lui, ma in caso contrario vai direttamente al capo.
  • Dato che il capo è stressato, salta la saga del dolore. Vai a destra Problema / Perché è grande / Perché la tua soluzione è buona. Tieni conto delle stime e degli impatti del tempo: se la progettazione errata costerà ad ogni sviluppatore un supplemento di 4-8 ore per attività e il refactoring del design richiederà 2 giorni, è quasi una soluzione imprudente. Offri al capo le prospettive a lungo termine che non ha il tempo di scoprire da solo.
  • Siate pronti a fare qualche sacrificio per avere la vostra strada. Spesso nei team con cui ho lavorato, il ragazzo che dice che è disposto a lavorare il fine settimana per rendere le cose giuste è il ragazzo che ottiene più gioco quando si tratta di prendere decisioni. Se è così profondamente investito, probabilmente è anche disposto a continuare a lavorare sulla sua soluzione se si incontrano altri problemi.
  • Conoscere le altre porte per ottenere quello che vuoi - c'è un manager e un architetto? Lo sviluppatore originale è un ragazzo così anziano che nessuno ha un pensiero originale senza eseguirlo da lui? Conoscere i giocatori e sapere come prendono le decisioni in modo da convincerli in modo rapido ed efficiente che è necessario risolvere il problema.
risposta data 15.06.2011 - 16:58
fonte
19

whoa there little buddy ... ci sono validi motivi per tutte le lamentele che hai segnalato. la denormalizzazione può essere perfettamente accettabile a seconda del profilo di accesso ai dati dell'applicazione (ad es. read-heavy, insert-heavy, reporting, ecc.). A volte 1nf è troppo ingombrante

Inoltre, un FK nullable non è davvero niente fuori dall'ordinario ... di nuovo, tutto dipende da cosa è usato.

Detto questo, questa risposta non sta dicendo che è giusto, non ho idea di cosa sia la tua app. Dicendo che ci sono sempre delle eccezioni alla regola; -)

    
risposta data 15.06.2011 - 16:29
fonte
12

Sono d'accordo con gli altri utenti che ci sono spesso buone ragioni per queste decisioni di progettazione (sebbene possano essere o meno applicabili nel tuo caso, non possiamo dire con le informazioni fornite), ecco alcune domande SO che riguardano gli "scioperi" che hai dato all'appaltatore:

Chiavi esterne Nullabili:

Denormalizzazione dei dati:

risposta data 15.06.2011 - 16:48
fonte
9

È un database di segnalazione? O forse uno schema di gestione temporanea per un feed di dati che riceve questi dati in questo formato e dovrà essere normalizzato dopo che è stato compilato?

Supponi di avere una ragione e di scoprire di cosa si tratta.

    
risposta data 15.06.2011 - 16:31
fonte
5

Cambiare i tipi di dati chiave e applicare i vincoli delle chiavi esterne è piuttosto semplice. Un sacco di tempo in cui le persone non li impostano nella fase iniziale, perché possono essere un rompicoglioni durante lo sviluppo.

Numeri di telefono ... Eh. Personalmente tendo a raggruppare i numeri di telefono nel proprio tavolo, perché consente un numero arbitrario di numeri di telefono per record, ma se si concede un solo telefono per record, ci sono benefici per mantenerli con il record.

E a volte i dati possono essere duplicati. Le tabelle con schema snowflake denormalizzato sono lo standard per le applicazioni ad alto volume.

In breve, assicurati di sapere perché prima di scaricare l'apprendimento del libro sullo sviluppatore senior

    
risposta data 15.06.2011 - 16:36
fonte
3

Senza contesto, è un po 'difficile rispondere, ma hai preso in considerazione le ragioni alla base della duplicazione e delle chiavi esterne nullable prima di ranting?

Sospetto che tu abbia ragione sull'uso dei campi bigint su tutta la linea, ma tieni presente che potrebbe esserci un uso. Se hanno in mano riferimenti a ID utente di Facebook, ad esempio, o ID di post di Twitter.

La chiave straniera Nullabile sembra perfettamente valida per me. Personalmente, di solito sono sospettoso quando ne vedo uno che è non nullable. Nel mondo reale, un ordine può avere un ID cliente nullo o un ID di fatturazione nullo. Una fattura può essere senza un ordine. Un pagamento senza fattura. E così via. Nullables sono dappertutto, e le app che non le permettono tipicamente non permettono di affrontare un sacco di situazioni che non dovrebbero sorgere in teoria, ma che si verificano invariabilmente nella realtà.

Anche la duplicazione del contenuto nel DB ha i suoi usi. In effetti, è usato proprio su questo sito. Hai mai notato come lo stesso utente può apparire più volte su una pagina piena di domande e avere una reputazione diversa in ciascuna di esse? Questo perché è memorizzato in un modo o nell'altro (presumibilmente con il nome) per evitare alcune query. La duplicazione può aumentare le prestazioni.

Altre volte, la duplicazione è effettivamente necessaria. Se il nome o l'indirizzo di un utente cambia o se il nome o il prezzo di un prodotto cambia, l'ultima cosa che desideri è modificare le fatture precedenti, che potrebbero essere necessarie ai fini fiscali.

Alla fine, chiedi perché questo / quello. Hai menzionato un altro dev due volte vecchio, quindi presumo che tu sia relativamente giovane. Chiedete e verificate se il ragazzo anziano ha effettivamente preso in considerazione un paio di cose a cui non avete nemmeno iniziato a pensare. Potresti essere sorpreso ...

    
risposta data 15.06.2011 - 16:41
fonte
1

Sembra che ci siano un sacco di cose che accadono al tuo componente e molta richiesta ai dipendenti. O:

  1. Lo sviluppatore non ha avuto il tempo di sistemare le cose e la soluzione "veloce e sporca" viene spostata nella produzione (non buona, ma anche comune).
  2. O vi sono alcuni requisiti o motivi per la progettazione.

In entrambi i casi, parlane con lo sviluppatore. Scopri se ci sono alcuni vincoli al di fuori della tua visione attuale. Se hai intenzione di subentrare nella manutenzione e non ci sono problemi, vai avanti e apporta correzioni e aggiustamenti in tempo utile per migliorarlo.

    
risposta data 15.06.2011 - 16:30
fonte
0

Di quelli la mia più grande preoccupazione sono i dati duplicati. Sì, questo può essere utile per ridurre i join e migliorare le prestazioni, tuttavia (ed è comunque un aspetto critico), se viene eseguito senza un modo automatico per mantenere i dati duplicati, si avranno problemi di integrità dei dati. A seconda della struttura dei dati questo potrebbe essere un aggiornamento a cascata e cancellare o un trigger, ma deve essere nel database (non l'applicazione) per essere efficace. Se questo è stato impostato, è più probabile che la persona sappia cosa stava facendo e lo ha fatto deliberatamente. In caso contrario, hai qualcosa da dire al tuo capo (probabilmente dopo la spinta iniziale alla produzione poiché è così vicino ma appena possibile) per mostrare che il design è difettoso e deve essere riparato.

Se hai intenzione di mantenere un database imperfetto e desideri passare a una struttura migliore nel tempo, devi leggere questo libro:

link

Per il futuro, si prega di sollevare le preoccupazioni con il design il più presto possibile. Le modifiche alla progettazione (in particolare ai database) sono molto più difficili da risolvere dopo che sono state apportate.

    
risposta data 15.06.2011 - 17:23
fonte
-5

Dubito strongmente che ci sia una buona ragione per configurare il database in questo modo. Le chiavi estranee che accettano valori nulla sono qualcosa che può modellare una relazione da 0 a molti, ma il fatto che OGNI relazione sia modellata in quel modo è sospetta.

Inoltre, nemmeno in 1NF? Perché persino usare un database si potrebbe anche usare solo file flat: /

Ho visto questo tipo di incompetenza prima. Nessuno sarà a conoscenza di un problema di progettazione come questo fino a un paio di anni lungo la strada quando i dati sono FUBAR. Quello che suggerirei è che ridisegnate discretamente il database. Se non riesci a farla franca senza affrontare il ragazzo anziano che l'ha fatto, allora parla discretamente con lui. Non metterlo sulla difensiva, farlo sentire incompetente e non avvicinarlo in un modo che lo faccia sentire un interesse personale nel tentare di difendere il suo design Fubar, ma non essere una figa a riguardo o. Non coinvolgere il suo capo e non farlo apparire incompetente. Basta sedersi con lui, ridisegnarlo e dargli alcuni suggerimenti. Forse suggerirgli un paio di buone risorse per apprendere i fondamenti relazionali del database di base.

Potrebbe essere che il ragazzo sia un fantastico codificatore di device driver o qualcosa del genere, ma è completamente privo di conoscenze quando si tratta di progettare un database. In ogni caso, non importa. Basta avere questo risolto ora mentre è ancora possibile.

eta: buoni punti su questo potrebbe essere un database di segnalazione. Questo è uno scenario diverso. Se si dispone di un database popolato da dump di dati periodici in batch provenienti da un altro sistema e non verrà utilizzato per inserimenti, aggiornamenti ed eliminazioni atomici, questo tipo di struttura può essere più utile per scopi di reporting.

Ho l'impressione basata sul post originale che probabilmente non è questo il caso. In ogni caso, è una ragione in più per usare il mio suggerimento. Basta andare dal dev e discuterne con lui. Parte di essere un membro prezioso della squadra significa avere un sacco ed essere disposti a confrontarsi e imparare l'uno dall'altro.

    
risposta data 15.06.2011 - 16:31
fonte

Leggi altre domande sui tag