É uma boa idéia salvar o inventário como uma série de “pulls” e “pushes” no banco de dados?

5

Estou projetando o banco de dados para um aplicativo que precisará rastrear o inventário. Não tenho certeza se é um bom design de banco de dados usar as tabelas "pull de inventários" e "inventários de inventário" para armazenar cada alteração no inventário e calcular a contagem de cada item com base nesses pulls e pushs.

Fazer isso dessa maneira me permitiria associar um "pull" a outra entidade de dados, como o funcionário que retirou o item ou a ordem pela qual o item foi retirado. Por outro lado, pode tornar a aplicação muito lenta no futuro quando a lista ficar realmente grande.

Eu preciso poder associar essas transações ("pulls" e "pushes") a outras entidades, mas estou preocupado com o desempenho do aplicativo. Se eu usar o método da tabela de inventário, precisaria rastrear esses dados em outro lugar.

Esta escolha de design faz sentido?

    
por Hassan 18.04.2017 / 18:15
fonte

1 resposta

7

Faz sentido armazenar push e pulls como eventos que possuem outras qualidades ou propriedades associadas a eles, como quem ou quando.

Também faz sentido armazenar a contagem real de inventário, já que esse número também é necessário.

Em outras palavras, esses dois não são necessariamente mutuamente exclusivos, embora os últimos possam ser derivados do antigo conjunto de transações: os engenheiros fazem escolhas para armazenar / armazenar informações deriváveis, com base em medido considerações de desempenho .

Armazenar eventos como um log somente de anexação é, em parte, o que está por trás de Sourcing de Eventos de Segregação de responsabilidade de consulta de comando .

O CQRS é uma abordagem de escalonamento que busca separar os caminhos de acesso por tipo (comando / solicitação vs. consulta). Isso acaba com um modelo de gravação segregado e o modelo de leitura. Assim, o modelo de gravação pode ser um banco de dados normalizado, enquanto o modelo de leitura é desordenado para consultas frequentes de aplicativos.

O Event Sourcing baseia-se nisso, usando um registro de eventos apenas como anexo, como a última fonte de verdade, permitindo reinicializações do sistema que criam os modelos de gravação e leitura dos eventos.

FYI, CQRS / ES é uma arquitetura complexa projetada para lidar com o desempenho em escala e, provavelmente, não é para todos. Internamente, faz múltiplas cópias da informação, em diferentes formas, para diferentes propósitos.

    
por 18.04.2017 / 18:37
fonte