Il mio collega ha creato una tabella SQL a 96 colonne

Eccoci nel 2010, ingegneri del software con 4 o 5 anni o esperienza, ancora progettando tabelle con 96 colonne di fracking.

Gli ho detto che sarà un incubo.
Gli ho mostrato che dobbiamo usare ordinali per interfacciare MySQL con C #.
Ho spiegato che le tabelle con più colonne che righe sono un odore enorme.

Tuttavia, ottengo il messaggio "Sarà più semplice in questo modo".

Cosa dovrei fare?

MODIFICARE *

Questa tabella contiene i dati dei sensori.
Abbiamo il sensore 1 con
Dynamic_D1X
Dynamic_D1Y
[...]

Dynamic_D6X
Dynamic_D6Y
[...]

EDIT2 *

Bene, ho finalmente lasciato quel lavoro. È un segno quando l'altro programmatore si oscura per mesi in quel momento, è un altro segno in cui il management non si rende conto che questo è un problema

Forse lo ha fatto per una buona ragione, come ad esempio spettacoli o ROI? .

La cosa migliore da fare è fargli domande. Con un certo "perché" gli farai certamente capire che probabilmente ha torto da solo (se lo è davvero).

Io stesso ho avuto un caso che non è legato alle prestazioni ma al ritorno sull'investimento (ROI). Avevo una tabella contenente oggetti che avevano un valore specifico per ogni ora della settimana (168 ore in una settimana). Abbiamo scelto 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 mettere 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 rispetto alla sua controparte ben progettata. Per lo stesso risultato esatto per il cliente.

Abbiamo deciso di optare per la soluzione semplice / economica per concentrare i nostri sforzi su cose 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 a grandi file flat. L'unico modo per migliorare è se qualcuno prende il comando e guida con l'esempio. Di recente ho guidato un'importante riprogettazione di uno schema importante nel nostro database e ho seguito le pratiche relazionali comuni. All'improvviso le nostre procedure archiviate sono diventate più eleganti e tutti gli indici corretti sembravano sistemarsi come se fossero nati per questo. Lo sviluppatore guidato dall'ego non ti crederà mai senza prove.

Qualcosa di simile è stato discusso in precedenza su StackOverflow .

In generale, avere molte colonne su una tabella non significa necessariamente che stai facendo qualcosa di sbagliato, ma sicuramente dovrebbe alzare alcune bandiere rosse in modo 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 l'archiviazione in due tabelle: una tabella che identifica le entità e un'altra tabella che è effettivamente un archivio chiave / valore di attributi che descrivono tali entità (quindi potresti finire con un massimo di 96 righeper ogni entità). Sono possibili anche altri disegni. Parla con i tuoi compagni di squadra e scopri quale soluzione è migliore a seconda della normalizzazione dei dati, della leggibilità del codice e della manutenibilità (inserisci istruzioni con 96 attributi da compilare?), Implicazioni sulle prestazioni, con quale frequenza è possibile aggiungere o modificare nuovi attributi (colonne), quanto scarso i dati sono (quante delle 96 colonne saranno mai riempite e quante resteranno NULL?) e le implicazioni sulla segnalazione. Qualsiasi sviluppatore dovrebbe essere in grado di giustificare ragionevolmente le proprie decisioni di progettazione e dimostrare che il compromesso costi / benefici (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 abbiano riflettuto su questi problemi.

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

È possibile che tu abbia 96 attributi separati per on entity.

Altrimenti, fagli leggere Joe Celko su Simple Talk

Dipende completamente.

I progetti di DB normalizzati / non normalizzati presentano entrambi i loro vantaggi e svantaggi.

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

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

Quindi potrebbe essere un odore, ma alcuni altri design DB avranno una propria deliziosa gamma di odori.

Fagli leggere questo articolo sul debito tecnico . Se decide ancora di mantenerlo così, allora almeno hai offerto un parere costruttivo.

Guardando il post (modificato), è chiaro che si tratta di una tabella mal denormalizzata. Cosa dovresti fare A mio avviso, hai alcune opzioni:

1. Urla al tuo collega per imparare a fare il suo lavoro. È improbabile che sia produttivo, ma probabilmente convincerà gli altri colleghi a non scherzare con te. Una reputazione come un maniaco urlante può essere utile (non chiedermi come lo so).
2. Grida al capo che il collega è un idiota. Prevedi il disastro, quindi lavora attivamente per sabotare il progetto. Dai la colpa a tutto sul design del database prodotto da un collega incompetente. Può portare direttamente a ...
3. Smettere. Meglio se è una tua idea, ma il n. 2 può portare a dimissioni involontarie. Cerca di non raschiare le ginocchia su asfalto / cemento / ghiaia se lanciato dalla finestra da un boss infuriato e / o colleghi. (Nota che lo studio precedente è IMPORTANTE qui. Le tue possibilità di sopravvivenza diminuiscono notevolmente se l'ufficio dei boss è al di sopra del piano terra e ti ritrovi ad essere spinto fuori dalla finestra. Pianifica in anticipo !! )
4. Bevi pesantemente - oppure, trasferisciti in California e accendi (supponendo che passi la 19 (o qualsiasi altra cosa)). Niente come pochi scatti e un doobie per migliorare la propria visione sui colleghi (o almeno così ho sentito). (Annuncio di servizio pubblico: BAMBINI! Queste persone sono professionisti! NON provatelo a casa!)

Condividi e divertiti.

Ho intenzione di uscire su un arto qui e presumere che taglierà e incolli molto codice per lavorare con questa "nuova" tabella.

In tal caso, 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 provata e vera che richiede una cosa a 96 colonne, considera gli effettivi benefici di farlo in un modo diverso in questo caso particolare. Se non ce ne sono, allora dagli il beneficio del dubbio, ma ricordagli che la prossima volta che vorresti partecipare alla fase di pianificazione, la prossima volta farà quella che tutti considereremmo una mossa piuttosto stupida.

Dipende totalmente dai casi d'uso dell'applicazione che accederà allo schema, quale blocco di dati è necessario alla volta. In qualche modo potrebbe giustificare il design del tavolo.

Lo manderei ai tempi della pietra e lo costringerei ad usare i file o almeno a insegnargli come usare i BLOB.

Davvero, 96 colonne ... Non può essere giusto, 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 fare il downgrade di tutto all'inferno 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. Raramente i programmatori sembrano pensare nelle forme degli insiemi e concentrarsi invece sull'utilizzo dei dati (piuttosto che mantenere la terza forma normale, l'indicizzazione o altri problemi di prestazioni del DB). Come programmatori tendiamo anche a non essere più d'accordo su quelle decisioni di architettura del DB di quanto forse dovremmo, basandoci sulla nostra inesperienza nella modellazione dei dati / problemi di architettura. IMHO, mi piace il fatto che io abbia architetti e modellatori di dati che soddisfano i requisiti, creano tabelle / proc / ecc. E mi occupano delle uscite.

Senza conoscere i motivi reali di questo progetto (ho lavorato su sensori meteorologici che hanno ben più di 96 diverse uscite numeriche = un gran numero di colonne della tabella) ... questo sembra solo sfogare una pipì da compagnia.