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

"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.

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; -)

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:

• Vantaggio delle chiavi esterne nullable
• chiavi esterne e null in MySQL
• Qualche esempio di chiave straniera nullable necessaria?
• Nullable cattiva pratica con chiave esterna

Denormalizzazione dei dati:

• Dovremmo denormalizzare il database per migliorare le prestazioni?
• Normalizza o denormalizza in siti Web con traffico elevato?

È 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.

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

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 ...

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.

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.

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.