【问题标题】:Database structure to handle similar/same object at varying business levels用于处理不同业务级别的相似/相同对象的数据库结构
【发布时间】:2015-10-06 14:27:41
【问题描述】:

场景

一家知名的 taco 机构想要使用模型 ComboComboItemIngredientOrder 构建一个 Django 应用程序。

  1. 总部想要创建包含项目的各种组合并布局原始项目成分和价格。
  2. 然后,每个特许经营商可以选择他们将在其菜单上销售的组合,并允许为他们的商店调整组合项目的价格和成分。
  3. 收到订单后,组合和项目详细信息应显示在日志中,并且如果总部重命名组合或特许经营权更改价格/成分,则不应在未来更改。

用例

  1. 总部创建了“Hot Taco Combo”。它有三个相关的组合项

    • 一个炸玉米饼(价格:0.99 美元,配料:贝壳、牛肉、奶酪、辣酱)
    • churro-spirals(价格:0.79 美元)
    • 饮料(价格:1.29 美元)
  2. 纽约特许经营店将 Hot Taco Combo 添加到他们的菜单中。他们将炸玉米饼的价格调整为 1.49 美元,并在炸玉米饼中加入生菜。

  3. 客户订购的套餐中没有奶酪。

  4. HQ 将组合的名称更改为 Fiery Taco Combo - 纽约的组合名称更新,但 taco 保持相同的定制价格,仍然包括生菜。

  5. 纽约特许经营店的一位经理查看了所有订单,并看到了一份 Hot Taco Combo 的订单,而炸玉米饼的原料只有壳、肉和生菜。

问题

我正在努力确定处理此问题的最佳方法,因为 Combo 在所有三个级别上基本上是相同的对象,但其相关的 ComboItem 对象可能不同。 HQ 应该能够更新 Combo 属性,例如名称,它会更新所有特许经营组合名称,但组合项目自定义应该保留。此外,为了准确的订单记录,销售点的组合详细信息和自定义设置一旦记录就不得更改。

最初我以为在每个业务级别从它们继承的每个相关模型和对象都有一个AbstractBaseClass,但这种结构感觉冗余且难以维护。

然后我想使用GenericForeignKey 将组合与总部、特许经营权或订单相关联,并在必要时在对象向下移动时复制对象。这感觉很奇怪且容易出错。

有没有人处理过这样的案例或有什么建议?这只是一个复杂的问题并需要一个复杂的解决方案,还是我缺少一种简单的方法?提前谢谢你。

【问题讨论】:

    标签: django data-modeling database-relations generic-foreign-key abstract-base-class


    【解决方案1】:

    听起来您希望使用多表继承而不是抽象基类:https://docs.djangoproject.com/en/1.8/topics/db/models/#multi-table-inheritance

    我建议通读整个文档部分,了解您对继承样式的选择:https://docs.djangoproject.com/en/1.8/topics/db/models/#model-inheritance

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2023-03-15
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-07-06
      • 2013-12-02
      • 2015-11-05
      相关资源
      最近更新 更多