Como desnormalizar um sistema de banco de dados fortemente normalizado?

Question

Estou procurando introduzir alguma desnormalização do banco de dados em um sistema fortemente normalizado.

Eu tenho um grande conjunto de bancos de dados que evoluíram em dez anos e estão sob crescentes quantidades de carga, por isso estou procurando melhorar o desempenho e possivelmente reduzir a complexidade de algumas consultas.

Não é incomum fazer 10 junções para realizar qualquer tarefa em um procedimento armazenado. Disseram -me que mais do que 6 fede.

Devo manter a estrutura da tabela como está e fornecer algumas vistas materializadas ou tabelas de "cache" desnormalizadas.

Alguns conselhos sobre as melhores práticas ou um empurrão na direção certa ajudariam.

Obrigado

Answer 1

Você não diz qual é o problema. É desempenho? Se sim, em que tabelas?

São realmente as junções que estão causando o problema? Ou são os procedimentos armazenados? Você não sabe (ou pelo menos, você não diz).

Prática recomendada: Descubra onde seus gargalos são os primeiros, antes de tentar resolver um problema que você ainda não diagnosticou.

---

Em edição: lembro -me de um tempo em que estava em um emprego quando tivemos um problema de desempenho. Procs armazenados muito lentos, que podem levar minutos para serem concluídos. Aconteceu que esses SPs estavam fazendo atualizações de tabela totalmente normais, mas usando cursores. Para coisas tão simples quanto update t set c = c + 1 where id = n.

Então, para fazer uma atualização, estávamos amaldiçoando um monte de linhas com um cursor de atualização caro e fazendo um declare cursor for "select c from t where id = n" for update; Em seguida, um cursor aberto e uma leitura e uma verificação de erro e um loop com uma verificação de leitura e erro e depois select c into @c; @c = c + 1; update t set c = @c where current of cursor; para cada atualização.

Acontece que o cara que escreveu isso não percebeu que poderíamos apenas emitir uma declaração de atualização. E assim ele escreveu dezenas desses procs lentos armazenados. Nem precisamos nos livrar dos Procs armazenados (embora isso também nos ganhasse alguma velocidade, isso teria mudado nosso cliente); Acabamos de nos livrar dos cursores, substituindo -os por instruções de atualização. Problema de desempenho se foi.

Answer 2

Algumas coisas para investigar

• Referência de todos os tempos de execução de consulta - dê a si mesmo uma métrica para comparar.
• Investigar a indexação é feita corretamente.
• Leia sobre Particionamento da tabela.
• Explorar sharding como uma opção.
• Veja suas junções de perto. Você está sempre juntando as mesmas mesas? Se a resposta não for tão óbvia, você ainda poderá criar divisões lógicas (como suas tabelas desnormalizadas) usando visualizações.

Answer 3

Tente indexar muito e sabiamente. Tente usar visualizações indexadas. Tente procedimentos armazenados pré -compilados. Se isso falhar, lembre -se de que desnormalizar e armazenar em cache geralmente exigem funcionários de sincronização pesada; portanto, você deve procurar cuidadosamente cada caso antes de fazê -lo.

Answer 4

Eu tenho que concordar, 10 junções são maus e matarão sua performance.

Depende muito de como seus aplicativos interagem com os bancos de dados. Se o seu código permanecer estritamente aos procedimentos armazenados (sem chamadas diretas de SQL), sua vida será mais fácil.

Se você estiver indo para o trabalho de desnormalização, eu não adicionaria novas tabelas "cache". Isso está realmente apenas corrigindo o problema. Eu iria em frente e formularia um plano completo para desnormalizar o banco de dados com um novo esquema otimizado.

Answer 5

Eu concordaria com Elijah. Certifique -se de comparar qualquer coisa que esteja prestes a mudar.

Além disso, dependendo das suas visualizações indexadas de configuração pode ser uma opção.