首页 文章

库存数据库设计[关闭]

提问于
浏览 次
70

这不是关于“编程”的问题（不是特定于任何语言或数据库），而是更多的设计和架构 . 这也是“什么是最好的X方式”的问题 . 我希望不会引起太多“宗教”的争议 .

在过去，我开发了以某种方式保留某种形式的物品清单（与物品无关）的系统 . 有些人使用不支持交易的语言/数据库 . 在这些情况下，我选择不在项目记录的字段中保存项目数量 . 而是计算总库存量 - 库存总量 . 由于软件的原因，这导致库存几乎没有差异 . 表格已正确编入索引，性能良好 . 如果记录量开始影响性能，则存在归档过程 .

现在，几年前我开始在这家公司工作，我继承了一个跟踪库存的系统 . 但数量保存在一个字段中 . 注册条目后，收到的数量将添加到项目的数量字段中 . 销售商品时，会减去数量 . 这导致了差异 . 在我看来，这不是正确的方法，但此前的程序员发誓它 .

我想知道是否就设计这样的系统的正确方法达成共识 . 还有哪些资源可用，印刷或在线，以寻求相关指导 .

谢谢

database inventory

13 回答

  • 5

    没有一列或两列，我的意思是“收到的库存总量 - 销售库存总量”是这样的：

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

    然后

    Qunatity_on_hand = inventory_received - inventory_sold

    请记住，我过度简化了这个和我的初步解释 . 我知道还有更多的库存只是跟踪数量，但在这种情况下，问题在于我们想要解决的问题 . 在这一点上，改变它的原因是支持当前设计引起的问题的成本 .

    另外我想提一下，虽然这不是一个“编码”问题，但与蚯蚓和设计有关，恕我直言是非常重要的主题 .

    到目前为止，感谢大家的答案 .

    尼尔森玛莫尔

    回复于
  • 15

    Django-inventory更适合固定资产，但可能会给你一些想法 .

    IE：ItemTemplate（class） - > ItemsOnHand（instance）

    ItemsOnHand可以链接到更多ItemTemplates;示例打印机和墨盒是必需的 . 这也允许为每个ItemOnHand设置重新订购点 .

    每个ItemsOnHand都链接到InventoryTransactions，这样可以轻松进行审核 . 为避免计算来自数千个投资交易的实际现有项目，使用的检查点只是日期的余额 . 要计算现有项目查询以查找最新检查点并开始添加或减少项目以查找项目的当前余额 . 定期定义新的检查点 .

    回复于
  • 2

    我已经在我现在的公司看到了两种方法，并且肯定会倾向于第一种方法（根据股票交易计算总数） .

    如果您只在一个字段中存储总数量，则您不知道如何到达该数字 . 没有交易历史记录，您最终可能会遇到问题 .

    我写的最后一个系统通过将每笔交易存储为具有正数或负数的记录来跟踪库存 . 我发现它运作得很好 .

    回复于
  • 4
    回复于
  • 3

    这取决于，库存系统不仅仅是计算物品 . 例如，出于会计目的，您可能需要基于FIFO（先进先出）模型了解库存的会计 Value . 这不能通过简单的“收到的库存总量 - 销售库存总量”公式来计算 . 但他们的模型可能很容易计算出来，因为他们会随着时间的推移修改会计 Value 我不想详细说明，因为这不是编程问题，但如果他们发誓，也许你并不完全理解他们必须满足的所有要求 .

    回复于
  • 1

    两者都有效，视情况而定 . 当满足以下条件时，前者最佳：

    • 要求的项目数量相对较少

    • 很少或没有特殊情况需要考虑（退货，调整等）

    • 不经常需要库存物料数量

    另一方面，如果您有大量项目，几个例外情况和频繁访问，维护项目数量将更有效

    另请注意，如果您的系统存在差异，则会出现应该跟踪并消除的错误

    我已经完成了两种方式的系统，两种方式都可以正常工作 - 只要你不忽略错误！

    回复于
  • 0

    看看ARTS（零售技术标准协会）数据模型（http://nrf-arts.org） . 它使用StockLedger表并记录每个项目，并在InventoryJournalEntries中跟踪对库存的更改 .

    回复于
  • 48

    考虑现有系统以及更改它的成本和风险非常重要 . 我使用的数据库存储与您类似的库存类型，但它包括审核周期和存储调整，就像收据一样 . 它似乎运作良好，但所有参与者都受过良好的培训，仓库工作人员并不是很快就能学会新的程序 .

    在您的情况下，如果您在不更改整个数据库结构的情况下寻找更多跟踪，那么我建议添加跟踪表（类似于“事务”解决方案），然后将更改记录到库存级别 . 将大多数更改更新到库存级别应该不会太难，这样它们也会留下交易记录 . 您还可以每隔几个小时左右添加一个定期任务来将库存级别备份到事务表中，以便即使您这样做也是如此错过发生变更时可以发现的事务或回滚到之前的状态 .

    如果你想看一个大型应用程序是如何做的，看看SugarCRM，他们有和库存管理模块，虽然我不知道它如何存储数据 .

    回复于
  • 9

    我会选择第一种方式，在哪里

    现有数量计算总收到的库存 - 销售库存总量

    正确的方式，IMO .

    EDIT: 我也想把系统中的任何库存损失/损坏考虑在内，但我相信你已经涵盖了这一点 .

    回复于
  • 3

    我认为这实际上是一个一般的最佳实践问题，关于每次需要总计时执行（相对）昂贵的计数，每次更改时执行计数，然后将计数存储在字段中并在需要时读取该字段总 .

    如果我不能使用交易，我会在每次需要总计时使用实时计数 . 如果交易可用，则可以安全地执行库存更新操作并在同一交易中保存重新计算的总数，这将确保计数的准确性（尽管我不确定这对多个用户是否有效）点击数据库） .

    但是，如果性能不是一个真正的大问题（现代数据库在计算行数方面已经足够好了，我甚至很少担心这个问题）我每次都会坚持使用实时计数 .

    回复于
  • 1

    我曾经研究过解决这个问题的系统 . 我认为理想的解决方案是预先计算的列，它可以让您获得两全其美的效果 . 你的总数将是一个字段，因此没有昂贵的查找，但它不能与其余数据不同步（数据库保持完整性） . 我不记得哪些RDMS支持预先计算的列，但如果您没有事务，则可能也不可用 .

    您可能使用触发器伪造预先计算的列（非常有效......我看不出任何缺点） . 你可能需要交易 . 恕我直言，在进行这种受控的非规范化时保持数据完整性是触发器的唯一合法用途 .

    回复于
  • 0

    我可以看到有两个列有一些好处，但我没有关注有关差异的部分 - 你似乎暗示有两列（进和出）比单列（当前）更不容易出现差异 . 这是为什么？

    回复于
  • 7

    我们解决了不同的问题，但我们对其中一些问题的处理方法可能对您有意义 .

    我们允许系统进行“最佳猜测”，并向用户定期反馈任何看起来错误的猜测 .

    要将此应用于广告资源，您可以拥有3个字段：

    inventory_received
inventory_sold
estimated_on_hand

    然后，您可以按以下方式运行一个流程（每天？）

    SELECT * 
FROM   Inventory
WHERE  estimated_on_hand != inventory_received - inventory_sold

    当然，这依赖于用户查看此警报并对其进行操作 .

    此外，您可以通过更新inventory_sold / received，或者添加另一个字段“inventory_adjustment”（可能是正面或负面）来重置库存的功能 .

    ......只是一些想法 . 希望它有用 .

    回复于

相关问题