Por favor, ajudam a explicar se eu estou destruindo minha DB Schema por causa do desempenho :(

Question

Eu tenho um banco de dados em produção para quase 3 anos, no Sql 2008 (era '05, antes disso). Tem sido bom, mas não é muito alto desempenho. Então, eu estou aprimorando o esquema e consultas para ajudar a acelerar algumas coisas. Além disso, uma pontuação de tabelas principais contêm cerca de 1-3 moinho de linhas, por tabela (para dar u uma estimativa sobre o tamanho).

Aqui está um diagrama de banco de dados (Soz, sob NDA assim que eu não pode exibir o original): -

alt texto http://img11.imageshack.us/img11/4608/dbschemaexample .png

coisas para nota (que estão diretamente relacionadas com o meu problema): -

• Um veículo pode ter 0 (NULL) ou 1 Radio. (Left Outer Join)
• Um veículo pode ter 0 (NULL) ou 1 Cupholder (Left Outer Join)
• Um veículo tem 1 Tipo do pneu (INNER JOIN).

Em primeiro lugar, isto parece um normalizada esquema de banco de dados. Eu chupar e teoria DB, então eu estou supondo que este é 3NF (pelo menos) ... últimas palavras famosas:)

Agora, isso está matando o meu desempenho de banco de dados, porque estas duas associações externas e junção interna estão sendo chamado de um monte e há também um pouco mais junta-se em muitas declarações.

Para tentar corrigir isso, eu pensei que eu poderia tentar e exibição indexada . Criando a vista é um pedaço de bolo. Mas indexando-lo, não funciona -> não pode criar exibições indexadas com junções ou tabelas auto referência (também outra prov :()

.

Então, eu chorei por horas (e / pulsos , cabelo tingido e escreveu um emo canção sobre isso e colocá-lo em myfailspace) e fez o seguinte ...

1. Adicionado uma nova linha em cada 'opcional' junção externa tabelas (neste exemplo, rádios e suportes para copos). ID = 0, resto dos dados = 'Desconhecido Blah' ou 0 do.
2. Atualização de tabelas pai, de modo que nenhum dos dados nulos têm agora um 0.
3. Atualização relação de junções externas de junta interior.

Agora, isso funciona. Posso até fazer a minha exibição indexada, que é muito rápido agora.

Então ... eu estou com dor. Isso só vai contra tudo o que foi ensinado. Eu me sinto sujo. Sozinho. Infectado.

Isso é uma coisa ruim para fazer? É este um cenário comum de desnormalizar um banco de dados por causa do desempenho?

Eu adoraria alguns pensamentos sobre isso, por favor:)

PS. Essas imagens de google aleatórios encontram -. Então me não

Answer 1

Banco de Dados deve sempre ser concebido e implementado inicialmente na 3NF. Mas o mundo é um lugar da realidade, não ideais, e não há problema em voltar a 2NF (ou até mesmo 1NF) por motivos de desempenho. Não bater-se sobre ele, o pragmatismo bate dogmatismo no mundo real o tempo todo.

A sua solução, se ele melhora o desempenho, é uma boa. A idéia de ter um rádio real (por exemplo), fabricado pela ninguém e não tendo recursos, não é um mau - que tem sido feito um muito antes, acredite em mim :-) A única razão você faria usar esse campo como NULL foi ver que os veículos não têm rádio e há pouca diferença entre estas consultas:

select Registration from vehicles where RadioId is null
select Registration from vehicles where RadioId = 0

O meu primeiro pensamento foi simplesmente combinar as quatro mesas em um e pendurar a questão de dados duplicados. A maioria dos problemas com DBMS' resultam de mau desempenho, em vez de baixo espaço de armazenamento.

Talvez manter isso como seu fallback posição se o seu atual esquema de-normalizado torna-se lento também.

Answer 2

valores nulos geralmente não são usados ??em indexs. O que você fez é fornecer um valor de sentinela para que a coluna sempre tem um valor que permite que seus índices para ser usado de forma mais eficaz.

Você não mudar a estrutura de seu banco de dados ou, então, eu não chamaria isso de desnormalizar. Eu tenho feito isso com valores de data onde você tem um nulo "data final" não denotado terminou ainda. Em vez eu fiz isso uma forma data conhecida no futuro o que permitiu a indexação.

Eu acho que isso é bom.

Answer 3

"... Então, eu estou aprimorando o esquema e consultas para ajudar a acelerar algumas coisas ..." - eu discordo sobre isso. Parece que você está abrandar as coisas. (Brincadeirinha).

I como o blog programador de banco de dados. Ele tem duas colunas a favor e contra a normalização que você pode achar útil:

1. http://database-programmer.blogspot.com /2008/10/argument-for-normalization.html
2. http://database-programmer.blogspot.com /2008/10/argument-for-denormalization.html

Eu não sou um DBA, mas acho que a prova é na frente de seus olhos: O desempenho é pior. Eu não vejo o que a divisão destes. 1: 1 relacionamentos em tabelas separadas está comprando você, mas eu vou ser feliz para receber instruções

Antes de eu mudei nada, eu ia perguntar SQL Server para EXPLAIN PLAN em cada consulta que foi lenta e usar essa informação para ver exatamente o que deve ser mudado. Não acho que porque um guru normalização avisei. Obter os dados para backup que você está fazendo. O que você está fazendo sons como otimização de código camada intermediária sem profiling. Gut sentimentos não são muito precisos.

Answer 4

eu estou correndo para o mesmo problema de desempenho vs excelência acadêmica. temos uma grande vista sobre um banco de dados de clientes com 300 colunas e 91000 registros. usamos junções externas para criar a visão eo desempenho é muito ruim. temos considerado mudando para associações internas, colocando nos registros fictícios com um valor de zero nas colunas que se juntam em (em vez de null) para permitir que um índice exclusivo na vista.

Eu tenho que concordar que, se o desempenho é importante, às vezes as coisas estranhas tem que ser feito para que isso aconteça. em última análise, aqueles que pagar nossas contas não me importo se a arquitetura é perfeito.