Il mio collaboratore ha creato una tabella SQL a 96 colonne

Forse l'ha fatto per una buona ragione, come le performance o il ROI? .

The best thing to do, is asking him questions. With a certain amount of "why" you will certainly make him understand he is probably wrong by itself (if he really is).

Ho avuto un caso che non è legato alle prestazioni ma al ritorno sull'investimento (ROI). Avevo una tabella contenente oggetti con un valore specifico per ogni ora della settimana (168 ore in una settimana). Abbiamo avuto la scelta di creare una tabella ObjectHour che contenga il valore, ma anche una chiave per l'oggetto e il numero del giorno del numero dell'ora. Ma abbiamo anche avuto l'opportunità di inserire i 168 valori nella riga. Probabilmente piace quello che ha fatto il tuo collega.

Gli sviluppatori hanno stimato entrambe le soluzioni. La soluzione semplice (168 colonne) era molto più economica da fare della sua controparte ben progettata. Per lo stesso identico risultato per il cliente.

Abbiamo deciso di optare per la soluzione semplice / economica per concentrare i nostri sforzi su aspetti più importanti come la sicurezza.

Avremo molte opportunità per migliorarlo in futuro. Il time to market era la priorità per noi al momento.

Sfortunatamente il tuo sviluppatore medio pensa ancora ai database relazionali come file flat grandi. L'unico modo in cui andranno meglio è se qualcuno prende in carico e conduce con l'esempio. Proprio di recente ho guidato una grande riprogettazione di uno schema importante nel nostro database e ho seguito pratiche di relazione comuni. All'improvviso le nostre procedure memorizzate erano più eleganti e tutti gli indici appropriati sembravano andare a posto come se fossero nati per questo. Lo sviluppatore guidato dall'ego non ti crederà mai senza prove.

Qualcosa di simile è stato discusso precedentemente su StackOverflow .

In generale, avere un sacco di colonne su un tavolo non significa necessariamente che stai facendo qualcosa di sbagliato, ma sicuramente dovrebbe alzare delle bandiere rosse così da guardare da vicino il design. A volte un tavolo enorme è la scelta giusta, ma in molti casi, altre alternative hanno più senso. Ad esempio, un'opzione è quella di dividere lo spazio di archiviazione in due tabelle: una tabella che identifica le tue entità e un'altra tabella che è effettivamente un archivio chiave / valore di attributi che descrivono tali entità (quindi potresti avere al massimo 96 righe per ogni entità). Sono possibili anche altri design. Parla con i tuoi compagni di squadra e scopri quale soluzione è migliore in base alla normalizzazione dei dati, leggibilità del codice e amp; manutenibilità (inserire istruzioni con 96 attributi da compilare?), implicazioni sulle prestazioni, con quale frequenza possono essere aggiunti o modificati nuovi attributi (colonne), quanto sparsi sono i dati (quante delle 96 colonne saranno mai riempite e quante rimangono NULL ?) e implicazioni sulla segnalazione. Qualunque sviluppatore dovrebbe essere in grado di giustificare ragionevolmente le proprie decisioni di progettazione e dimostrare che il rapporto costo / beneficio (e sì, ogni decisione di progettazione è un compromesso) è a loro favore. La tua responsabilità non è quella di lamentarti o criticare, ma di proporre alternative e assicurarti che riflettano su questi argomenti.

È normalizzato con 96 colonne? Soddisfa 1 °, 2 °, 3 ° ecc. NF?

Può darsi che tu abbia 96 attributi separati per l'entità.

Altrimenti, fagli leggere Joe Celko su Simple Talk

Dipende completamente.

I progetti di DB normalizzati / non normalizzati hanno entrambi vantaggi e svantaggi.

Il mio primo progetto di DB era una cosa normalizzata di bellezza. Era flessibile ed estensibile. È stato anche un incredibile PITA per chiunque, tranne me stesso, a che fare con il livello di codice, ed è stata una PITA leggera per me.

Il mio prossimo tentativo era una struttura piatta, ed era (a) molto più veloce e (b) molto più facile da codificare. E non sarà un compito ingrato normalizzare più tardi.

Quindi potrebbe essere un odore, ma qualche altro progetto di DB avrà la sua deliziosa serie di odori.

Fagli leggere questo articolo sul debito tecnico . Se decide ancora di tenerlo in questo modo, almeno hai offerto un'opinione costruttiva.

Guardando il post (modificato), è chiaro che questa è una tabella male denormalizzata. Cosa dovresti fare? A mio avviso, hai alcune opzioni:

1. Urla al tuo collega per imparare come fare il suo lavoro. Improbabile che sia produttivo ma probabilmente convincerà altri colleghi a non scherzare con te. Una reputazione come maniaco urlante può essere utile (non chiedermi come faccio a saperlo).
2. Scream al capo quel collega è un idiota. Prevedere il disastro, quindi lavorare attivamente per sabotare il progetto. Dare la colpa a tutto sul design del database prodotto da un collega incompetente. Può portare direttamente a ...
3. Esci. Meglio se è la tua idea, ma il # 2 può portare a dimissioni involontarie. Cerca di non graffiare le ginocchia su asfalto / cemento / ghiaia se scagliato dalla finestra da boss e / o colleghi infuriati. (Nota che lo studio preliminare è IMPORTANTE qui. Le tue possibilità di sopravvivenza diminuiscono notevolmente se l'ufficio dei capi si trova al di sopra del piano terra e ti ritrovi a essere spinto fuori dalla finestra. Pianifica in anticipo !! )
4. Bevi molto - o, spostati in California e accenditi (assumendo il supporto 19 (o qualsiasi altra cosa) passi). Niente come pochi scatti e una doobie per migliorare la propria visione dei propri colleghi (o almeno così ho sentito). (Annuncio di servizio pubblico: KIDS! Queste persone sono professionisti! NON provarlo a casa!)

Condividi e divertiti.

Vado qui su un arto qui e suppongo che sta andando a tagliare e incollare un sacco di codice per lavorare con questa tabella "Nuovo".

Se è così, probabilmente non dovrai sostenere alcun debito tecnico aggiuntivo. Ha appena diviso la sua parte di debito tecnico e potrebbe essere sulla buona strada per una sorta di grande unificazione delle cose.

Se ha una metodologia collaudata e vera che richiede una colonna da 96 elementi, considera i reali vantaggi di farlo in un modo diverso in questo caso particolare. Se non ce ne sono, concedigli il beneficio del dubbio, ma ricordagli che la prossima volta che vorrai partecipare alla fase di pianificazione la prossima volta farà ciò che tutti consideriamo una mossa stupida.

Dipende totalmente dai casi d'uso dell'applicazione che accederà allo schema, quale porzione di dati è necessaria alla volta. In qualche modo potrebbe giustificare il design della tabella.

Lo spedirei alle età della pietra e costringerlo a usare i file o almeno a insegnargli come usare i BLOB.

Davvero, 96 colonne ... Non può essere vero, mai. Forse un ORM sarebbe d'aiuto. (A meno che tu non abbia bisogno di prestazioni ma puoi avere qualcuno che capisca meglio DB per gestirlo)

Ho intenzione di ottenere downvoted tutto al diavolo per questo, ma questo è esattamente il motivo per cui ho separato le responsabilità della modellazione dei dati e dell'ingegneria del software nel mio negozio. I programmatori raramente sembrano pensare nelle forme di insiemi e concentrarsi invece sull'utilizzo dei dati (piuttosto che mantenere la terza forma normale, l'indicizzazione o altri problemi di prestazioni del DB). Noi, come programmatori, tendiamo anche a non essere più d'accordo su quelle decisioni architettoniche di DB di quanto dovremmo, sulla base della nostra inesperienza in pura modellizzazione dei dati / questioni architettoniche. IMHO, mi piace il fatto che io abbia architetti e modellatori di dati che prendono i requisiti, costruiscono tabelle / procs / ecc. E mi occupano delle uscite.

Senza conoscere le reali ragioni di questo progetto (ho lavorato su sensori meteorologici che hanno ben oltre 96 uscite numeriche diverse = un gran numero di colonne di tabelle) ... sembra proprio come sfogare un pisello.