Dúvida modelagem de movimentação de estoque

MySQL

Java

Automação Comercial

Infraestrutura

06/10/2016

Olá a todos, a partir de hoje vou passar a dar manutenção em um sistema de almoxarifado desenvolvido por um colega que foi desligado da empresa.
Neste sistema tenho uma tabela chamada "COMPRAS" e uma outra tabela chamada de "REQUISIÇÕES", e toda vez que acontece uma compra ou requisição, também é adicionado uma linha na tabela "MOVIMENTOS", nesta tabela movimentos tenho um campo que guarda a chave tanto para uma compra ou para uma requisição e outro campo que guarda o tipo de operação: entrada ou saída, por exemplo no dia 06/10/2016 realizei uma requisição no valor de R$ 10,00 e uma compra no valor de R$ 36,00:

<table>
<tr>
<th>movimento_id</th>
<th>com_req_id</th>
<th>tipo_movimento</th>
<th>material_id</th>
<th>valor_unitario</th>
<th>valor_total</th>
<th>data</th>
</tr>
<tr>
<td>1</td>
<td>50</td>
<td>ENTRADA</td>
<td>67</td>
<td>2.50</td>
<td>10</td>
<td>06/10/2016</td>
</tr>
<tr>
<td>2</td>
<td>15</td>
<td>SAIDA</td>
<td>48</td>
<td>12</td>
<td>36</td>
<td>06/10/2016</td>
</tr>
</table>


este tipo de modelagem segue as boas práticas de modelagem de dados? fere alguma regra de modelagem ou pode me trazer problemas? é comum modelar dessa forma, utilizando uma coluna tanto para um tipo de transação ou outra e outra coluna para especificar o tipo da transação?
Ricardo Pereira

Ricardo Pereira

Curtidas 0

Melhor post

Hélio Devmedia

Hélio Devmedia

14/10/2016

Ricardo, no tópico do artigo não estava muito bem explicado mas vendo agora entendi bem o problema.

Fere de varias maneiras a forma normal, alem de outros princípios de modelagem em banco relacional. E ainda gera um problema de logica.

Primeiro q não eh possível criar uma chave estrangeira que relacione um campo com duas tabelas simultaneamente. Acredito eu q esse campo chave eh só nominal, ou seja, não tem realmente uma restrição criada na tabela e um índice associado a ela o que faz a busca por estoque ser lenta, e calcular estoque eh algo q precisamos calcular quase instantaneamente.

Segundo, esta criando redundância de dados. Se a compra for excluída e a movimentação não for, o estoque estará errado.

Mais um, você esta criando uma brecha para gerar relatórios de vários lugares diferentes. Um vai gerar a partir das movimentações, e outro pode acabar gerando a partir das compras. Assim fica duas fontes diferentes para coletar dados.

Sugiro basear-se tudo nas duas tabelas, construa uma view para juntar as duas tabelas. E questões de estoque use a view para consultar.

Espero ter sido util. Caso tenha sido, de um joinha para eu saber.
GOSTEI 1

Mais Respostas

Luiz Santos

Luiz Santos

06/10/2016

Ricardo.
Não existe uma resposta certa ou errada nesse caso.
Temos que entender o processo para ver se está sendo contemplado ou não.
Normalmente um processo de estoque funciona como uma conta corrente, com entradas (depósitos) e saídas (saques) de material(ais).

Grande abraço
GOSTEI 0
Ricardo Pereira

Ricardo Pereira

06/10/2016

Olá Luiz, na abordagem que meu amigo utilizou, tanto as entradas quanto as saídas de cada material são registradas nessa tabela de movimentação, só que ele utilizou apenas uma coluna "com_req_id" para armazenar a chave estrangeira pertencente à entrada(compra) ou saída(requisição), uma coisa boa dessa abordagem é que elimina aquela coisa chata de se ter sempre uma coluna nula no banco caso nessa tabela de movimentação eu tivesse as colunas compra_id e requisicao_id, mas também como está hoje acho que foge um pouco da normalização pois só tenho a coluna com_req_id, então não consigo adicionar a constraint indicando que ela é uma foreign key, pois não existe foreign key apontando para duas tabelas(pelo menos eu acho que não existe), o istema está em produção e funcionando bem, mas queria saber se existe uma solução melhor tratand-se de boas práticas de modeagem, ou se mesmo não seguindo 100% o modelo normal, se essa forma que ele fez é a forma mais utilizada por outros desenvolveedores ou dbas
GOSTEI 0
POSTAR