As relações são mais lentas que uma tabela grande e ineficiente?

No meu trabalho, fui solicitado a violar a primeira forma normal (repetir grupos em colunas, usando valores vazios / nulos) várias vezes, "por causa do poder de processamento do computador". Em poucas palavras, uma tabela "aluno" deve ter pelo menos 8 campos vazios (por exemplo, telefones: telefone1, telefone2, telefone3 ...) em vez da minha sugestão - uma tabela "telefone" que contém um número de telefone (e possíveis outros metadados) e a chave estrangeira é o número de identificação do aluno. Meu chefe diz que é melhor armazená-los dessa maneira porque "há menos ciclos de CPU e isso importa nas plataformas da Web", em vez de usar relações. Eu digo que, no pior dos casos, é insignificante.

Nesse exemplo, o uso de relações (suponha que as tabelas sejam preenchidas com muitos registros em um aplicativo da Web de tamanho médio) é notavelmente mais lento que o uso desse tipo de esquema de tabela?

— AeroCross
fonte

Acredito que seria realmente mais rápido fazer o que seu chefe diz, mas você tem a tarefa possivelmente torturante de garantir que não receba anomalias de atualização. Mas poderia criar muito mais trabalho cpu se você precisar alterar um pedaço de dados que é comum para a mesa (ala mudança do código de área para todos os números de telefone ...)

— Patrick

Eu duvido seriamente, no hardware moderno, desde que você tenha indexado suas chaves estrangeiras que a CPU extra seria mensurável, especialmente no outro lado de um servidor da web. No meu site, temos tabelas normalizadas e servimos bem a norte de 50.000 hits / s sem suar a camisa. Diga ao seu chefe para se dedicar ao golfe e deixar as decisões técnicas para você!

— Caio

@ Patrick Você acredita que é consideravelmente mais rápido ou marginalmente mais rápido? E acho que, assim como a @Gaius - no hardware moderno, mesmo que seja "mais rápido", o ganho de velocidade e durabilidade do hardware é insignificante.

— AeroCross

Eu acho que a melhoria da velocidade é inconseqüente. Somente se você tiver conjuntos de dados massivos e fizer junções ridículas, você perceberá alguma diferença perceptível no desempenho.

— Patrick

Não vejo como alguém poderia fazer tal afirmação sem ter fatos reais para apoiá-la. Se suas consultas estiverem vinculadas à CPU, você deve procurar maneiras de reduzir esse gargalo.

Parece que seu chefe acha que um banco de dados desnormalizado terá melhor desempenho, mas não sei o suficiente sobre seu aplicativo para dizer se isso está certo ou não. Qual será o número esperado de exclusões, atualizações e inserções para esta tabela?

Eu esperaria que esse design desnormalizado possa resultar em uma quantidade reduzida de tempo de CPU, mas esperaria que a E / S do disco aumentasse. E as leituras físicas do disco serão muito mais caras que um ciclo de CPU, portanto, talvez seu chefe tenha uma métrica muito específica a ser atendida (CPU) e, como resultado, queira um design muito específico? Nesse caso, eu simplesmente criaria o que é solicitado e manteria as métricas no custo da CPU para as consultas que estão sendo executadas. Se você observar um aumento no tempo, poderá sugerir algumas alterações no design.

De fato, é provavelmente uma boa idéia obter uma lista de todas as métricas que seu chefe deseja ver e acompanhar essas medidas ao longo do tempo.

— SQLRockstar
fonte

O fato é que ele é da velha escola - em seus dias (20 anos?) Talvez tenha sido importante, como ele propõe, mas o hardware e o software de hoje são muito, muito poderosos e, por design, são mais rápidos assim. É difícil lidar com alguém assim, porque ele tem mais poder e o "fato" empírico (mas desatualizado) de que é MAIS rápido, e deve ser considerado dessa maneira.

— AeroCross

Entendido. tente fazê-lo listar as métricas (CPU, disco IOO) que ele deseja medir e o que ele considera aceitável. basta medir esses itens e, quando tudo der errado, você poderá oferecer algumas alternativas. Dessa forma, você pode obter um design melhor implantado sem brigas; apenas deixe seu design provar a si mesmo ao longo do tempo. é um ganha-ganha, na verdade.

— SQLRockstar 16/03/11