我正在努力寻找关于以下主题的更好方法，并希望得到任何建议。
一、说明：
数据库用途——仓库存储。有几个实体，例如：
- t_resource（来自产品的制造）。
- t_product（由资源制成的最终产品）。
- t_rack 存储项目的位置。
- t_item 可以是产品或资源的类型。
2.问题：
如何以适合项目的方式抽象资源和产品并在以后轻松搜索。
3. 我的想法和可能的解决方案：
- 引入名称为“type”的 t_item 表列，这将有助于区分资源和产品的 id -> 这种方法似乎有很大的缺点，特别是如果我想加入代表表以带来产品和资源的详细信息。
- 为 t_rack 存储引入独立的表并拆分为 t_rack_res 和 t_rack_product -> 当需要显示两个表中的所有项目时，此解决方案可能会遇到相同的问题。稍后如果需要缩放项目类型，我将陷入创建另一个表的问题。
- 将产品和资源合并到一张表中——我不喜欢这个想法的唯一原因是，实际上这两件事是不同的，应该分开，因为产品应该由资源制成并包含它。
我会接受你的第一个建议 - Item 有一个“类型”列。在实践中，缺点并没有那么糟糕。
您已将产品和资源建模为不同的业务实体。它们必须具有不同的属性和过程。如果不是，它们将是同一个实体并在同一个表中建模。
任何作用于产品的实际过程都可以读取产品表并读取/写入特定于产品的那些值。对于任何影响资源的进程也是如此。很可能产品操作集和资源操作集是完全分开的。例如，您可以销售产品，但不能销售资源；您可以将资源加工成产品，但不能反过来。
Product 和 Resource 共有的那些属性以及与它们相关的是 Items（定义为可以放在机架上的任何东西），例如重量、尺寸，作为列存储在 Item 中。再一次，与物品操作相关的过程（放在架子上、从架子上取货、遵守负载限制等）不需要知道产品（单价、营销名称、最小订单数量）或资源（供应商地址、重新订购交货时间）。
对于那些需要同时来自 Item 和 Product/Resource 的属性的罕见情况，可以将子类型 OUTER JOINed 到 Item。
如果您拆分 Rack，您确实会遇到同样的问题。存放产品的机架与存放资源的机架不太可能有任何显着差异。这些 to 实际上具有相同的属性并允许相同的过程，因此应建模为单个实体，因此应建模为表。
将产品和资源合并为一个也是可行的。如果不同的属性很少，则更是如此。如果有很多差异，那么系统需要知道哪些列是为哪种类型填充的，哪些列不能是，并且您回到了两个单独的处理机制，它们只是粘在一起并且有很多 NULL。