Usuários pedindo banco de dados desnormalizado

Question

Estou nos estágios iniciais do desenvolvimento de um sistema orientado ao banco de dados e a maior parte do sistema gira em torno de um tipo de relacionamento de herança. Há uma entidade pai com cerca de 10 colunas e haverá cerca de 10 entidades infantis herdando dos pais. Cada entidade filho terá cerca de 10 colunas. Eu pensei que fazia sentido dar à entidade pai sua própria tabela e dar a cada uma das crianças suas próprias mesas-uma estrutura de mesa por subclasse.

Hoje, meus usuários pediram para ver a estrutura do sistema que eu criei. Eles recusaram a idéia da estrutura de mesa por sub-subclasse. Eles preferem uma grande tabela de colunas ~ 100, porque seria mais fácil para eles realizarem suas próprias consultas personalizadas.

Devo considerar desmoronizar o banco de dados em prol dos usuários?

Answer 1

Absolutamente não. Você sempre pode criar uma visão mais tarde para mostrar o que eles querem ver.

Answer 2

Eles estão efetivamente pedindo um relatório.

Você poderia Dê -lhes acesso a uma visão Contendo todos os campos que eles precisam ... dessa forma, você não estraga seu modelo de dados.

Answer 3

Não. Estruture os dados corretamente e se os usuários precisarem da visão desnormalizada dos dados, crie -os como uma visualização no banco de dados.

Como alternativa, considere que talvez um RDBMS não seja a ferramenta de armazenamento apropriada para este projeto.

Answer 4

Eles são os usuários e não os programadores do sistema por um motivo. Forneça uma interface separada para suas consultas. Usuários elétricos como esse podem ser úteis e uma dor de lidar. Apenas explique que você precisa do banco de dados projetado de uma certa maneira para poder fazer seu trabalho, ponto final. Uma vez que isso é realizado e forneça outros meios para facilitar a consulta.

Answer 5

O que eles sabem!? Você poderia argumentar que usuários Nem deveria ter acesso direto a um banco de dados em primeiro lugar.

Isso deixa você aberto a enormes problemas de desempenho, apenas porque alguns usuários estão executando consultas ridículas.

Answer 6

Que tal se você criou uma visualização no formato que seus usuários desejavam, mantendo uma tabela adequadamente normalizada?

Answer 7

Além de muitas das razões técnicas a favor ou contra a proposição de seus usuários, você precisa estar na mesma página para comunicar as consequências de vários cenários e (mais importante) o custos dessas consequências. Se os usuários são seus clientes e estão pagando para você fazer um trabalho, explique que deles horrível As idéias "propostas" podem custar mais dinheiro em tempo de desenvolvimento, recursos adicionais de hardware etc.

Espero que você possa explicá -lo de tal maneira que mostre sua experiência e por que sua ideia é um valor muito melhor para seus usuários a longo prazo.

Answer 8

Como todos mais ou menos mencionados, dessa maneira está a loucura, e você sempre pode construir uma visão.

Se você simplesmente não conseguir que eles apareçam nesse ponto, considere mostrar a eles esse tópico e o número de profissionais que pesaram ao dizer que os usuários estão se intrometeram com coisas que eles não entendem completamente, e o impacto será um fundação prejudicada.

Uma grande parte do ofício do desenvolvedor é a sensação do que não funciona a longo prazo, e as regras de normalização são quase canônicas nesse aspecto. Há situações em que você precisa desnormalizar (data warehouses, etc.), mas isso não parece um deles!

Também parece que você pode ter uma marca de usuário particularmente preocupante em sua mão - o desenvolvedor da Amatuer que pensa que poderia fazer seu trabalho melhor se eles tivessem tempo. Isso pode ou não ajudar, mas descobri que esses tipos respondem bem à apresentação - algumas vezes agora eu descobri que, se eu me vesti nítido e mostre um pouco de força em minha personalidade, isso os ajuda Sou especialista e evita um monte de problemas antes de começarem.

Answer 9

Eu recomendo fortemente apresentar uma resposta que não envolva alguém executando relatórios diretos no seu banco de dados. No momento que acontece, sua estrutura de banco de dados é colocada em pedra e você pode considerá -la basicamente legado.

Uma visão é um bom começo, mas mais tarde você provavelmente desejará estruturar isso como uma exportação, para se afastar ainda mais. Obviamente, você encontrará dados de alguém que deseja dados "em tempo real". A análise comercial adequada geralmente revela que isso é desnecessário. Os requisitos reais em tempo real não são melhor tratados através de sistemas de relatórios.

Só para ficar claro: eu pessoalmente favoreceria a tabela por abordagem da subclasse, mas não acho que seja um problema tão grande quanto as tabelas de transação de relatórios diretos.

Answer 10

Eu optaria por uma visualização (como outros sugeriram) ou uma função com valor de tabela em linha (os benefícios disso é que você precisa de parâmetros - como um intervalo de data ou uma conta de cliente - que pode ajudar a impedir que os usuários consultem sem limites em o espaço do problema) primeiro. Uma TVF embutida é realmente uma visão parametrizada e está muito mais próxima de uma visão em termos de como o mecanismo os trata do que com uma função avaliada por tabela de várias estatatos ou uma função escalar, que pode ter um desempenho incrivelmente ruim.

No entanto, em alguns casos, isso pode afetar o desempenho da produção se a visão for complexa ou intensiva. Com consultas de usuário ad hoc mal escritas, isso também pode fazer com que os bloqueios persistissem por mais tempo ou sejam escalados mais do que em uma consulta melhor construída. Também é possível que os usuários interpretem mal um modelo de dados e produza números multiplicados nos casos em que há muitos relacionamentos para muitos ou muitos para muitos. A próxima opção pode ser materializar essas visualizações com índices ou fazer tabelas e mantê -las atualizadas, o que nos aproxima da minha próxima opção ...

Portanto, dadas as desvantagens da opção de visualização e já pensando em mitigá-la, começando a fazer cópias de dados, a próxima opção que eu consideraria é ter uma versão separada de leitura (para esses usuários) dos dados que são estruturados de maneira diferente . Normalmente, eu primeiro olhava para um esquema de estrelas no estilo Kimball. Você não precisa ter um data warehouse de Data-Data, consistente de tempo completo. Obviamente, isso é uma opção, mas você pode simplesmente manter um modelo de relatório atualizado com os dados. Os esquemas das estrelas são uma forma especial de desnormalização e são particularmente bons para relatórios numéricos, e uma determinada estrela não deve ser abusada pelos usuários acidentalmente. Você pode manter a estrela atualizada de várias maneiras, incluindo gatilhos, trabalhos programados etc. Eles podem ser muito rápidos para relatar necessidades e executar na mesma instalação de produção - talvez em uma instância separada, se não apenas um banco de dados separado.

Embora essa solução possa exigir que você efetivamente mais do que o dobro de seus requisitos de armazenamento, quando comparado com outras práticas, pode ser uma opção realmente boa se você entender bem seus dados e não se importa de ter dois modelos - um para transações e outro para análise (Observe que você já começará a ter essa separação lógica de qualquer maneira com o uso de A a primeira opção de visão mais simples).

Alguns arquitetos geralmente dobram seus servidores e usam o mesmo modelo com algum tipo de replicação para fornecer um servidor de relatório que é indexado de maneira mais fácil ou diferente. Esse segundo servidor não afeta as transações de produção com os requisitos de relatório e pode ser mantido atualizado com bastante facilidade. Haverá apenas um modelo, mas é claro que isso tem os mesmos problemas de usabilidade em permitir que os usuários tenham acesso ad hoc apenas ao modelo subjacente, sem o desempenho afeta, pois eles recebem seu próprio playground.

Existem muitas maneiras de esfolar esses gatos. Boa sorte.

Answer 11

O cliente está sempre certo. No entanto, é provável que o cliente recue quando você converter seus requisitos em dólares e centavos. Uma tabela de 100 colunas exigirá tempo de desenvolvimento extra Para escrever o código que faz o que o banco de dados faria automaticamente com a implementação adequada. Além disso, deles Os custos de suporte serão maiores Como mais código significa mais problemas e menor facilidade de depuração.

Answer 12

Vou interpretar o advogado do diabo aqui e dizer que ambas as soluções soam como aproximações ruins dos dados reais. Há uma razão pela qual as linguagens de programação orientadas a objetos não tendem a ser implementadas com nenhum desses modelos de dados, e não é porque as idéias de 1970 sobre as relações de Codd eram o sistema ideal para armazenar e consultar estruturas de dados orientadas a objetos. :-)

Lembre -se de que o SQL foi originalmente projetado como uma linguagem de interface do usuário (é por isso que parece vagamente como inglês e não como outros idiomas daquela época: Algol, C, Apl, Prolog). As únicas razões pelas quais ouvi por não expor um banco de dados SQL aos usuários hoje são a segurança (eles podem derrubar o servidor!) E usabilidade (quem deseja escrever SQL quando você pode clicar em clicar?), Mas se for o servidor deles e eles Quer, então por que não deixá -los?

Dado que "a maior parte do sistema gira em torno de um tipo de relacionamento de herança", então eu consideraria seriamente um banco de dados que me permite representar nativamente PostGres (Se o SQL for importante) ou um banco de dados de objeto nativo (que é incrível de trabalhar, se você não precisar de compatibilidade com SQL).

Finalmente, lembre -se de que toda decisão de engenharia é uma troca. Ao "aderir às suas armas" (como outra pessoa propôs), você está implicitamente dizendo que o valor dos desejos de seus usuários é zero. Não peça uma resposta correta para isso, porque não sabemos o que seus usuários querem fazer com seus dados (ou mesmo quais são seus dados ou quem são seus usuários). Vá dizer a eles por que você deseja uma solução de muitas mesas e, em seguida, trabalhe uma solução com eles que é aceitável para vocês dois.

Answer 13

Você implementou Herança da tabela de aula E eles estão pedindo Herança de tabela única. Ambos os projetos são válidos em determinadas situações.

Você pode querer obter uma cópia do Martin Fowler Padrões de arquitetura de aplicativos corporativos ler mais sobre as vantagens e desvantagens de cada design. Esse livro é uma referência clássica em sua estante, em qualquer caso.