Como superar as deficiências nos relatórios da base de dados EAV?
https://stackoverflow.com/questions/2523741
-
22-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Todas as principais deficiências dos designs de banco de dados Entidade-Atributo-Valor em SQL parecem estar relacionadas à capacidade de consultar e relatar os dados de maneira eficiente e rápida.A maioria das informações que li sobre o assunto alertam contra a implementação do EAV devido a esses problemas e à semelhança de consultas/relatórios para quase todos os aplicativos.
Atualmente estou projetando um sistema onde os campos de uma das entidades não são conhecidos em tempo de design/compilação e são definidos pelo usuário final do sistema.O EAV parece ser uma boa opção para esse requisito, mas devido aos problemas sobre os quais li, estou hesitante em implementá-lo, pois também existem alguns requisitos de relatórios bastante pesados para este sistema.EU pensar Eu descobri uma maneira de contornar isso, mas gostaria de fazer a pergunta à comunidade SO.
Dado que o banco de dados normalizado típico (OLTP) ainda nem sempre é a melhor opção para a execução de relatórios, uma boa prática parece ser ter um banco de dados de "relatórios" (OLAP) onde os dados do banco de dados normalizado são copiados, indexados extensivamente e possivelmente desnormalizado para facilitar a consulta.A mesma ideia poderia ser usada para contornar as deficiências de um projeto EAV?
A principal desvantagem que vejo é o aumento da complexidade da transferência de dados do banco de dados EAV para relatórios, pois você pode acabar tendo que alterar as tabelas no banco de dados de relatórios à medida que novos campos são definidos no banco de dados EAV.Mas isso dificilmente é impossível e parece ser uma compensação aceitável para a maior flexibilidade proporcionada pelo desenho do EAV.Essa desvantagem também existe se eu usar um armazenamento de dados não SQL (ou seja,CouchDB ou similar) para o armazenamento de dados principal, uma vez que todas as ferramentas de relatório padrão esperam um back-end SQL para consulta.
Os problemas com os sistemas EAV desaparecem principalmente se você tiver um banco de dados de relatórios separado para consulta?
EDITAR:Obrigado pelos comentários até agora.Uma das coisas importantes sobre o sistema em que estou trabalhando é que estou falando apenas sobre o uso do EAV para uma das entidades, não para tudo no sistema.
A essência do sistema é ser capaz de extrair dados de múltiplas fontes diferentes que não são conhecidas antecipadamente e processar os dados para chegar a alguns dados “mais conhecidos” sobre uma entidade específica.Portanto, cada "campo" com o qual estou lidando tem vários valores e também sou obrigado a rastrear o histórico de cada um.O design normalizado para isso acaba sendo 1 tabela por campo, o que torna a consulta um tanto dolorosa.
Aqui estão os esquemas de tabela e os dados de amostra que estou analisando (obviamente alterados em relação ao que estou trabalhando, mas acho que ilustra bem o ponto):
Tabelas EAV
Person
-------------------
- Id - Name -
-------------------
- 123 - Joe Smith -
-------------------
Person_Value
-------------------------------------------------------------------
- PersonId - Source - Field - Value - EffectiveDate -
-------------------------------------------------------------------
- 123 - CIA - HomeAddress - 123 Cherry Ln - 2010-03-26 -
- 123 - DMV - HomeAddress - 561 Stoney Rd - 2010-02-15 -
- 123 - FBI - HomeAddress - 676 Lancas Dr - 2010-03-01 -
-------------------------------------------------------------------
Tabela de relatórios
Person_Denormalized
----------------------------------------------------------------------------------------
- Id - Name - HomeAddress - HomeAddress_Confidence - HomeAddress_EffectiveDate -
----------------------------------------------------------------------------------------
- 123 - Joe Smith - 123 Cherry Ln - 0.713 - 2010-03-26 -
----------------------------------------------------------------------------------------
Projeto Normalizado
Person
-------------------
- Id - Name -
-------------------
- 123 - Joe Smith -
-------------------
Person_HomeAddress
------------------------------------------------------
- PersonId - Source - Value - Effective Date -
------------------------------------------------------
- 123 - CIA - 123 Cherry Ln - 2010-03-26 -
- 123 - DMV - 561 Stoney Rd - 2010-02-15 -
- 123 - FBI - 676 Lancas Dr - 2010-03-01 -
------------------------------------------------------
O campo "Confiança" aqui é gerado usando uma lógica que não pode ser expressa facilmente (se é que pode ser expressa) usando SQL, então minha operação mais comum, além de inserir novos valores, será extrair TODOS os dados sobre uma pessoa para todos os campos, para que eu possa gerar o registro para o tabela de relatórios.Isso é na verdade mais fácil no modelo EAV, pois posso fazer uma única consulta.No design normalizado, acabo tendo que fazer 1 consulta por campo para evitar que um produto cartesiano massivo junte todos eles.
Solução
Resposta curta - sim, um banco de dados de relatórios é uma abordagem razoável para resolver os problemas de relatórios a partir de um modelo de dados EAV.
Passei vários anos trabalhando com uma solução de gerenciamento de informações que permitia aos usuários finais total liberdade para definir seu próprio modelo de dados, com o esquema e os dados armazenados usando um modelo EAV.Curiosamente, este produto forneceu objetos de metaesquema usados para atender aos requisitos de relatórios (por exemplo,gráficos para fornecer navegação de objetos, visualizações para realizar projeções, etc.).Isso significava que o usuário final estava livre para definir consultas usando os mesmos termos e conceitos usados para construir o modelo de dados na primeira instância.O ato de relatar consistia essencialmente em calcular o conjunto de dados navegando por essas definições e entregar o resultado a uma ferramenta tradicional de elaboração de relatórios, como se fossem dados relacionais.
Um dos pontos fortes desta abordagem foi que o mesmo mecanismo que já existia para transformar o modelo EAV em algo com o qual o usuário pudesse trabalhar poderia ser reutilizado e aplicado à função de relatório.
Outras dicas
Neste esquema, primeiro criamos um sistema que permite aos usuários armazenar qualquer tipo de dado, independentemente de sua estrutura e do uso futuro pretendido.Então, quando chegar a hora de divulgar os relatórios, teremos que descobrir o que temos e como isso se relaciona com o que precisamos.
Uma vez que atribui claramente a natureza do problema a "estar neste esquema", parece-me realmente que o problema com o EAV realmente é devido ao EAV como tal.
Na verdade, pensando bem:“um sistema que permite aos usuários armazenar qualquer tipo de dado” equivale a um sistema que permite aos usuários apenas definir seus valores de referência.Mas que parte desse sistema permite que os usuários definam restrições em cada atributo?Ops, o pessoal do EAV parece ter perdido um aspecto não tão importante do gerenciamento de dados, ao que parece...
O problema com o EAV não se deve ao EAV como tal.Isso se deve ao projeto e construção de um banco de dados sem entender quais são realmente os requisitos de dados e qual estrutura lógica os dados devem ter para atender a esses requisitos.O EAV, e qualquer outro sistema que permita aos usuários projetar seus próprios dados, vira isso de cabeça para baixo.
Neste esquema, primeiro criamos um sistema que permite aos usuários armazenar qualquer tipo de dado, independentemente de sua estrutura e do uso futuro pretendido.Então, quando chegar a hora de divulgar os relatórios, teremos que descobrir o que temos e como isso se relaciona com o que precisamos.
Boa sorte com isso.
Não há problema com o EAV. Gasto muito tempo consultando bancos de dados MASSIVE EAV.Qualquer pessoa que diga que reportar do EAV é difícil ou impossível tem 1 de 2 problemas: ou tem um sistema EAV muito mal projetado ou não entende como consultar um.obter bons dados passíveis de relatório de um banco de dados EAV é bastante fácil depois de fazer isso algumas vezes.Não há necessidade de um banco de dados de relatórios ou algo especial, apenas algumas boas consultas.
Se você estiver construindo um banco de dados EAV e gaste MUITO tempo projetando-o, o design irá fazer ou quebrar seu aplicativo e será um pesadelo tentar consertar ou lidar com um aplicativo mal projetado.
