design de banco de dados de inventário [fechado]

https://stackoverflow.com/questions/287097

08-07-2019
|

Pergunta

Esta é uma pergunta não é realmente sobre "Programação" (não é específico para qualquer idioma ou banco de dados), mas mais de design e arquitetura. É também uma questão do tipo "Qual a melhor maneira de fazer X". Espero que nenhum motivo para muita controvérsia "religiosa".

No passado, eu ter sistemas desenvolvidos que, de uma forma ou de outra, mantêm alguma forma de inventário de itens (não é relevante o que os itens). Alguns usando linguagens / DB de que não suportam transações. Nesses casos eu não optou por salvar item quantidade disponível em um campo no registro de item. Ao contrário, o quantidade disponível inventário é calculado somando recebido - total do inventário vendido. Isso resultou em quase nenhuma discrepância no inventário por causa de software. As tabelas são devidamente indexados e o desempenho é bom. Há um processo de arquivamento no caso da quantidade de registro começam a afetar o desempenho.

Agora, alguns anos atrás eu comecei a trabalhar nesta empresa, e eu herdei um sistema que inventário faixas. Mas a quantidade é salvo em um campo. Quando uma entrada é registrado, a quantidade recebida é adicionado ao campo de quantidade para o item. Quando um produto é vendido, a quantidade é subtraída. Isso resultou em discrepâncias. Na minha opinião esta não é a abordagem certa, mas os programadores anteriores aqui jurar por ele.

Eu gostaria de saber se existe um consenso sobre o que é o caminho certo é a concepção de tal sistema. Também o que recursos estão disponíveis, impresso ou on-line, para buscar orientação sobre este assunto.

Graças

Solução

Eu vi ambas as abordagens na minha empresa atual e com certeza gostaria de inclinar-se para o primeiro (calcular totais com base em transações de ações).

Se você estiver armazenando apenas uma quantidade total em um algum lugar campo, você não tem idéia de como você chegou a esse número. Não há nenhuma história transacional e você pode acabar com problemas.

O último sistema Eu escrevi estoque faixas, armazenando cada transação como um registro com uma quantidade positiva ou negativa. Eu encontrei ele funciona muito bem.

Outras dicas

Eu tenho Vol 1 e Vol 2 e estes têm sido bastante útil no passado.

Depende, sistemas de inventário são sobre muito mais do que apenas itens de contagem. Por exemplo, para fins contábeis, pode ser necessário conhecer os valores de inventário com base em FIFO modelo (First-in-first-out) respondendo. Isso não pode ser calculado pela simples "inventário totalizando recebido - total do inventário vendido" fórmula. Mas seu modelo pode calcular isso facilmente, porque eles modificar o valor contábil como eles vão. Eu não quero entrar em detalhes porque este não é programação problema, mas se eles juram por ele, talvez você não entender completamente todas as suas necessidades que eles têm para acomodar.

Ambos são válidos, dependendo das circunstâncias. O primeiro é melhor quando as seguintes condições são:

o número de itens a soma é relativamente pequeno
existem poucos ou nenhuns casos excepcionais a considerar (retornos, ajustes, et al)
a quantidade do item de inventário não é necessário muito frequentemente

Por outro lado, se você tem um grande número de itens, vários casos excepcionais, e acesso frequente, será mais eficiente para manter a quantidade do item

também notar que, se o seu sistema tem discrepâncias em seguida, que tem bugs que devem ser perseguidos e eliminados

i ter sistemas feito em ambos os sentidos, e em ambos os sentidos pode funcionar muito bem - contanto que você não ignore os erros

Dê uma olhada nas ARTS (Associação para Retail Technology Standards) do modelo de dados ( http://nrf-arts.org ). Ele usa uma tabela StockLedger com um registro de cada item e alterações ao inventário são todos monitorados em InventoryJournalEntries.

É importante considerar o sistema existente e o custo eo risco de mudá-lo. Eu trabalho com um banco de dados de inventário lojas tipo de como isso acontecer, mas inclui ciclos de auditoria e armazena ajustes assim como recibos. Parece que funciona bem, mas todos os envolvidos é bem treinado, e os funcionários do armazém não são exatamente rápido de aprender novos procedimentos.

No seu caso, se você está procurando um pouco mais de rastreamento sem alterar toda a estrutura db então eu sugiro adicionar uma tabela de rastreamento (tipo como da sua solução de 'transação') e, em seguida, log alterações ao inventário nível. Não deve ser muito difícil para atualizar a maioria das alterações ao nível de estoque para que eles também deixar um registro da transação. Você também pode adicionar uma tarefa periódica para fazer backup do nível de estoque para a mesa de operação a cada duas horas ou assim de modo que mesmo se você perder uma transação que você pode descobrir quando a mudança aconteceu ou reverter para um estado anterior.

Se você quiser ver como um aplicativo grande que é preciso uma olhada SugarCRM , eles têm e inventário módulo de gestão que eu não sei como ele armazena os dados.

Eu acho que esta é realmente uma questão geral de melhores práticas sobre como fazer uma contagem (relativamente) caro cada vez que você precisa de um total de vs. fazendo que contam cada vez que algo muda, então armazenar a contagem em um campo e lendo esse campo sempre você precisa de um total.

Se eu não poderia usar transações, eu iria com a contagem ao vivo cada vez que eu precisava de um total. Se as transações estão disponíveis, seria seguro para realizar as operações de actualização do inventário e da economia do total contado-re dentro da mesma transação, o que garantiria a precisão da contagem (embora eu não tenho certeza que isso iria trabalhar com múltiplos usuários bater o banco de dados).

Mas se o desempenho não é realmente um problema enorme (e bancos de dados modernos são bons o suficiente em linhas de contagem que eu raramente se preocupar com isso) eu tinha acabado de ficar com a contagem ao vivo cada vez.

Eu optaria pela primeira maneira, onde

a quantidade disponível é calculada totalizando inventário recebido - total de inventário vendido

O Caminho Certo, IMO.

EDIT:. Eu também gostaria de levar em consideração quaisquer perdas de estoque / danos no sistema, mas tenho certeza de que você tem que cobria

Eu trabalhei em sistemas que resolvem este problema antes. Acho que a solução ideal é uma coluna precomputed, que você obtém o melhor dos dois mundos. O seu total seria um lugar de campo, portanto, há pesquisas caros, mas não pode sair da sincronia com o resto de seus dados (o banco de dados mantém a integridade). Não me lembro que o apoio RDMSs colunas pré-computados, mas se você não tem transações, que podem não estar disponíveis também.

Você poderia colunas pré-computadas potencialmente falsos (de forma muito eficaz ... Eu vejo nenhuma desvantagem) usando disparadores. Você provavelmente precisará transações embora. IMHO, mantendo a integridade dos dados quando você está fazendo este tipo de desnormalização controlado é o uso somente legítimo que um gatilho.

Django-inventário mais orientada para ativos fixos, mas pode dar-lhe alguma ideias.

IE: ItemTemplate (classe) -> ItemsOnHand (instância)

ItemsOnHand pode ser ligado a mais ItemTemplates; Exemplo impressora e os cartuchos de tinta é necessário. Isso também permite definir pontos Reordenar para cada ItemOnHand.

Cada ItemsOnHand está ligada a InventoryTransactions, este permite a fácil auditoria. Para evitar cálculo real nos itens mão de milhares de transações invetory, postos de controle são usados ??que são apenas um equilíbrio + uma data. Para calcular itens em consulta mão para encontrar o ponto de verificação mais recente e começar a adicionar ou subtrair itens para encontrar o saldo atual de itens. Definir novos postos de controle periodicamente.

Eu posso ver algum benefício para ter as duas colunas, mas eu não estou seguindo a parte sobre discrepâncias - você parece estar dando a entender que ter as duas colunas (dentro e fora) é menos propenso a discrepância de uma única coluna ( atual). Por que isso?

Não está tendo uma ou duas colunas, o que quis dizer com "totalizando inventário recebido - total do inventário vendido" é algo como isto:

Select sum(quantity) as inventory_received from Inventory_entry
Select sum(quantity) as inventory_sold from Sales_items

então

Qunatity_on_hand = inventory_received - inventory_sold

Por favor, tenha em mente que eu simplificado isso e minha explicação inicial. Eu sei que há muito mais para inventário que apenas manter o controle de quantidades, mas, neste caso, que eram as mentiras de problema e o que queremos correção. Neste ponto, a razão para mudá-lo é preciselly o custo de suporte os problemas causados ??pelo projeto atual.

Também eu queria dizer que não, embora este é um "codificação" questão está relacionada com algoritmos e design que IMHO são temas muito importantes.

Obrigado a todos por suas respostas até agora.

Nelson Marmol

Nós resolver problemas diferentes, mas nossa abordagem para alguns deles pode ser interessante para você.

permitir que o sistema para fazer uma "melhor palpite", e dar aos usuários feedback regular sobre qualquer uma dessas suposições que errado olhar.

Para aplicar esta para o inventário, você poderia ter 3 campos:

inventory_received
inventory_sold
estimated_on_hand

Em seguida, você pode executar um processo (diária?) Ao longo das linhas de:

SELECT * 
FROM   Inventory
WHERE  estimated_on_hand != inventory_received - inventory_sold

Claro, isso depende de usuários olhando para esse alerta e fazer algo sobre isso.

Além disso, você poderia ter uma função para inventário de redefinição de alguma forma, seja por meio da atualização inventory_sold / recebidos, ou talvez adicionando um outro campo "inventory_adjustment", o que pode ser positivo ou negativo.

... apenas alguns pensamentos. Espero que seja útil.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow