Le relazioni sono più lente di una grande tabella inefficiente?

Nel mio lavoro mi è stato chiesto di violare più volte il primo modulo normale (ripetendo i gruppi attraverso le colonne, usando valori vuoti / nulli), "per motivi di potenza di elaborazione del computer". In breve, una tabella "studente" dovrebbe avere almeno 8 campi vuoti (ad esempio telefoni: telefono1, telefono2, telefono3 ...) invece del mio suggerimento: una tabella "telefono" che contiene un numero di telefono (e possibili altri metadati) e la chiave esterna è il numero ID dello studente. Il mio capo afferma che è meglio archiviarli in quel modo perché "ci sono meno cicli della CPU e questo conta nelle piattaforme web", invece di usare le relazioni. Dico che, nel peggiore dei casi, è trascurabile.

In quell'esempio, usare le relazioni (supponiamo che le tabelle siano piene di molti record in una webapp di medie dimensioni) è notevolmente più lento dell'uso di quel tipo di schema di tabelle?

— AeroCross
fonte

Credo che sarebbe effettivamente più veloce fare come dice il tuo capo, ma hai il compito possibilmente lancinante di assicurarti di non ottenere anomalie di aggiornamento. Ma potrebbe creare molto più lavoro sulla CPU se dovessi mai cambiare un dato comune al tavolo (ala cambiare il prefisso per tutti i numeri di telefono ...)

— Patrick

Dubito seriamente, sull'hardware moderno, purché tu abbia indicizzato le tue chiavi esterne che la CPU aggiuntiva sarebbe persino misurabile, specialmente dall'altra parte di un server web. Sul mio sito abbiamo tavoli normalizzati e serviamo ben a nord di 50.000 colpi / sec senza sudare. Di 'al tuo capo di restare fedele al golf e di lasciarti le decisioni tecniche!

— Gaius,

@Patrick Credi che sia considerevolmente più veloce o solo leggermente più veloce? E penso proprio come @Gaius: sull'hardware moderno, anche se è "più veloce", il guadagno di velocità e durata dell'hardware è trascurabile.

— AeroCross

Penso che il miglioramento della velocità sia irrilevante. Solo se disponi di enormi set di dati e stai eseguendo un ridicolo join, vedresti una notevole differenza nelle prestazioni.

— Patrick,

Non vedo come chiunque possa fare una simile affermazione senza avere alcuni fatti concreti per sostenerla. Se le tue query sono legate alla CPU, dovresti cercare i modi per ridurre il collo di bottiglia.

Sembra che il tuo capo pensi che un database denormalizzato funzionerà meglio, ma non so abbastanza sulla tua applicazione per dire se è giusto o no. Quale sarà il numero previsto di eliminazioni, aggiornamenti e inserti per questa tabella?

Mi aspetto che un tale design denormalizzato possa comportare una riduzione del tempo di CPU, ma mi aspetto che l'I / O del disco aumenti. E le letture fisiche dal disco saranno molto più costose di un ciclo CPU, quindi forse il tuo capo ha una metrica molto specifica da soddisfare (CPU) e di conseguenza vuole un design molto specifico? In tal caso, vorrei semplicemente creare ciò che viene richiesto e mantenere le metriche sul costo della CPU per le query in esecuzione. Se vedi un aumento del tempo, potresti voler suggerire alcune modifiche al design.

In effetti, è probabilmente una buona idea ottenere un elenco di tutte le metriche che il tuo capo vuole vedere e tracciarle nel tempo.

— SQLRockstar
fonte

Il fatto è che è vecchia scuola - ai suoi tempi (20 anni?) Forse era importante, come propone, ma l'hardware e il software di oggi sono molto, molto potenti, ed è, per progettazione, più veloce in quel modo. È difficile avere a che fare con qualcuno come questo, perché ha più potere e il "fatto" empirico (ma obsoleto) che È più veloce e dovrebbe essere considerato in quel modo.

— AeroCross

inteso. prova a fargli elencare le metriche (CPU, disco I? O) che desidera misurare e ciò che considera accettabile. poi semplicemente misura quegli oggetti e quando le cose vanno male potresti offrire delle alternative. in questo modo puoi distribuire un design migliore senza combattere; lascia che il suo design si dimostri nel tempo. in realtà è una vittoria.

— SQLRockstar