É correto persistir uma propriedade computada no banco de dados?

Question

É correto persistir uma propriedade computada no banco de dados?

#1 resposta do (5 votos)
#2 resposta do (1 votos)

5

Gostaria de saber o que você acha da persistência de uma "propriedade autocomputada" no banco de dados. Por exemplo eu tenho essas propriedades

decimal Price {get;set;}
decimal Tax {get;set;}
decimal PriceWithTax {get {return Price + Tax;}}

Acho que preciso persistir PriceWithTax . Eu posso usar essa coluna, por exemplo, em modos de exibição de banco de dados. Mas sinto que esta solução pode levar a erros ocultos. O que você acha?

Edit: Ok, tento explicar nosso problema real. Nós temos uma classe "Ordem", que tem coleção de itens - classe ItemOrders. Classe ItemOrder tem propriedade Preço e classe Ordem tem propriedade TotalPrice. E implementação do TotalPrice:

TotalPrice {get { return ItemOrders.Sum(i => i.Price); }}

E precisamos de classificação, agrupamento no banco de dados. Portanto, não é uma regra de negócios, mas uma "regra de dados".

design database-design

por Marek 16.03.2014 / 19:06

fonte

2 respostas

1

Colunas computadas não adicionam nada aos seus dados, e eles quebram o principal DRY - você está repetindo seus dados.

Se você quiser usar a coluna computada para seus modos de exibição, AFAIK, a maioria dos bancos de dados hoje suporta colunas computadas em seus modos de exibição (o que significa: você define a coluna em sua exibição em como Tax + Price ).

A única razão pela qual eu posso pensar nisso exigiria que você salvasse dados computados é se o cálculo não é trivial e consome tempo / cpu / memória, caso em que o cálculo na inserção irá liberá-lo de fazer o cálculo e de novo.

Outro motivo pode ser que você possa criar um índice na coluna computada para facilitar a pesquisa. Atualmente, a maioria dos bancos de dados também oferece suporte a algum tipo de índices baseados em função , que serão superiores solução.

por 16.03.2014 / 19:52

fonte

Tags design database-design

Precisão de "algoritmos de calculadora" Faz sentido dividir uma interface multi-método existente em várias interfaces de método único apenas para aproveitar lambdas?

score 5 · Accepted Answer

A primeira pergunta que você deve se fazer é se essa é uma regra de negócios ou algo puramente relacionado a dados .

Por exemplo, os impostos que uma pessoa deve pagar todo ano dependem de várias regras de negócios complexas. Essas regras estão sujeitas a alterações frequentes, portanto, é insensato fazer uma coluna computada contendo essas informações. Por outro lado, um dia e um mês de nascimento da pessoa extraída da data de nascimento completa não depende de regras de negócios, e é muito improvável que ela mude durante a vida útil do aplicativo; Assim, criar uma coluna computada para isso parece bem.

No seu exemplo, é difícil dizer com certeza sem contexto adicional, mas suponho que o preço com imposto seja uma regra de negócios. E se houvesse clientes que não deveriam pagar um imposto? E se o imposto fosse diferente de caso para caso?

A segunda pergunta a ser feita é se o armazenamento da coluna computada beneficiaria seu aplicativo . No meu exemplo anterior com a data de nascimento, pode fazer sentido armazenar essas informações adicionais em um contexto em que você deve pesquisar com frequência pessoas com base em seu dia e mês de nascimento, independentemente do ano de nascimento.

No seu caso, se o preço com imposto é tão simples quanto a adição de preço e imposto, por que criar uma coluna adicional? Como isso facilitaria ou agilizaria sua aplicação?