Qualquer boa literatura sobre se juntar desempenho vs desnormalização sistemática?

Question

Como corolário esta questão Eu queria saber se existe foi bons estudos comparativos que eu poderia consultar e passar adiante sobre as vantagens de usar os RDMBS fazer a otimização vs desnormalizar sistematicamente, a fim de sempre aceder a uma única tabela em um momento participar.

Especificamente eu quero informações sobre: ??

• Desempenho ou normalização contra desnormalização.
• Escalabilidade de normalizada vs sistema desnormalizada.
• questões de manutenção do desnormalização.
• questões modelo de consistência com desnormalização.

Um pouco de história para ver onde estou indo aqui: Nosso sistema usa uma camada de abstração de banco de dados in-house, mas é muito antiga e não pode lidar com mais de uma tabela. Como tal todos os objetos complexos têm de ser instanciado utilizando várias consultas em cada uma das tabelas relacionadas. Agora para garantir que o sistema usa sempre uma única mesa pesada desnormalização sistemática é usado ao longo das mesas, às vezes achatamento dois ou três níveis de profundidade. Quanto n-n relacionamento que parecia ter trabalhado em torno dele por elaborar cuidadosamente o seu modelo de dados para evitar tais relações e sempre voltar a cair 1-n ou n-1.

O resultado final é um sistema extremamente complexo complicado onde o cliente muitas vezes se queixam de desempenho. Ao analisar tais gargalo não questionam estas premissas básicas em que o sistema se baseia e sempre olhar para outra solução.

Eu perdi alguma coisa? Eu acho que a idéia é errado, mas de alguma forma não têm a provas irrefutáveis ??para provar (ou refutar), este é o lugar onde eu estou voltando para sua sabedoria coletiva para apontar-me para o bem, bem aceito, literatura que pode convencer outros colegas na minha equipe nesta abordagem é errada (de me convencer de que eu sou apenas muito paranóico e dogmática sobre modelos de dados consistentes).

Meu próximo passo é construir o meu próprio banco de ensaio e reunir os resultados, desde que eu odeio reinventar a roda Eu quero saber o que há sobre o assunto já.

---- EDIT Notas: o sistema foi construído com arquivos simples, sem um sistema de banco de dados ... só mais tarde foi portado para um banco de dados porque um cliente insistiu no sistema usando Oracle. Eles não refatorar mas simplesmente adicionou suporte para bancos de dados relacionais ao sistema existente. suporte arquivos simples foi posteriormente abandonada, mas ainda estamos aguardando refatora para tirar vantagens de banco de dados.

Answer 1

um pensamento: você tem uma impedância de mis-match claro, uma camada de acesso a dados que permite o acesso a apenas uma mesa? Pare aí, isso é simplesmente incompatível com uma utilização optimizada de um banco de dados relacional. Bancos de dados relacionais são projetados para fazer consultas complexas muito bem. Não ter outra de voltar uma tabela única opção, e, presumivelmente, fazer qualquer ingressar na camada bausiness, simplesmente não faz sentido.

Para a justificação da normalização, e os potenciais custos de consistência que você pode se referir a todo o material de Codd em diante, consulte a Wikipedia artigo .

Eu prevejo que a aferição desse tipo de coisa será uma atividade interminável, casos especiais serão abundantes. Eu afirmo que a normalização é "normal", as pessoas obter um bom desempenho suficiente fro um deisgn banco de dados limpo. Talvez uma abordagem poderia ser uma pesquisa: "Como normalizado é seus dados Escala de 0 a 4.?"

Answer 2

Tanto quanto eu sei, Modelagem Dimensional é a única técnica de desnormalização sistemática que tem alguma teoria por trás dele. Esta é a base da Data Warehousing técnicas .

DM foi iniciada por Ralph Kimball em " A Dimensional Modeling Manifesto " em 1997. Kimball também escreveu uma série de livros. O livro que parece ter as melhores críticas é " O Data Warehouse Toolkit: The Complete Guide to Modelagem dimensional (segunda Edição) "(2002), embora eu não li ainda.

Não há nenhuma dúvida de que desnormalização melhora o desempenho de certos tipos de consultas, mas fá-lo à custa de outras consultas. Por exemplo, se você tem um relacionamento muitos-para-muitos entre, digamos, Produtos e Ordens (em uma aplicação de comércio eletrônico típico), e você precisa que ele seja mais rápido para consultar os produtos de uma determinada Ordem, então você pode armazenar dados em uma forma desnormalizada para suportar isso, e ganhar algum benefício.

Mas o que torna mais complicado e ineficiente para consultar todos os pedidos para um determinado produto. Se você tem uma necessidade igual a fazer ambos os tipos de consultas, você deve ficar com o desenho normalizado. Isto atinge um compromisso, dando ambas as consultas desempenho semelhante, embora nem vai ser tão rápido como eles seriam na concepção desnormalizada que favoreceu um tipo de consulta.

Além disso, quando você armazenar dados de forma desnormalizada, você precisa fazer um trabalho extra para garantir a consistência. Ou seja, sem duplicação acidental e integridade referencial não quebrado. Você tem que considerar o custo da adição verificações manuais para a consistência.