Database 何时拆分到另一个DB表

我的问题是关于数据库以及何时拆分为其他表。我正在为多个平台制作一个库存跟踪器。例如，我有一个

Item

资源，我将连接到不同的平台，如Foo和Bar，它们有

Item

s。有名称、数量、sku、条形码等共享属性，但平台具有特定于它们的不同属性。他们将有自己的唯一ID，Foo可能有标签，Bar可能没有但有供应商标签。现在我所做的是这样的：

Item
- id
- name
- sku
- barcode
... bunch of others
- foo_id
- foo_tags
- foo_product_type

---

但是，如果我与Bar platform集成，我是否应该向

项

资源添加字段，如

Bar\u id

，

Bar\u供应商

，

Bar\u其他属性

？或者应该将其创建为另一个表，并且项将具有该表的外键？何时应将这些特定于平台的属性拆分为另一个表？就性能而言，额外的连接是否会使速度变慢？例如，如果我正在为一个用户更新所有这些项目，我将加入

用户

，

商店

，

项目

，现在可能是

平台特定项目数据

，我不知道是否有太多表要加入并影响性能的情况。

老实说，有时候这可能很难做到。我经常使用数据库，但很少有数据库真的那么大，不像行那么大，而是像字段那么大。通常是5张或更少的桌子

但根据我的经验，分解表的次数越多，以后扩展数据库、编辑或维护数据库就越容易。这可能看起来很愚蠢，但是想象一下，如果所有这些都在一个表中，那么使用起来会非常简单，但是现在如果您将标记更改为其他内容，其中有2个字段而不是1个字段，以此类推，会怎么样呢。或者如果你有一个系统仍然需要旧版本的标签，但是新系统没有使用它，你不能现在就删除它们，是吗？将其拆分可以让您获得更大的灵活性

我建议将所需信息放在主表中，其余部分分开。如果您没有那么丰富的经验，这可能会使查询速度减慢一点，并且创建适当的查询会变得更加困难，但从长远来看，当您开始改变事情时，这是值得的

items
    - id
    - name
    - sku
    - barcode
items_physical_properties
    - id
    - items_id
    - width
    - height
    - weight
    - quantity
    - color
items_digital_properties
    - id
    - items_id
    - tags
    - image
items_information
    - id
    - items_id
    - manufacturer
    - manufactured_date
    - vendor
    - company
    - created_date
items_pricing
    - id
    - items_id
    - sell_price
    - cost_price
items_sales
    - id
    - items_id
    - sale_price
    - start_date
    - end_date
    - amount_sold

我会把它分成这样的部分，原因是，假设你创建了一个第三方api或idk一个收银机，这样你就更容易限制你给他们的东西。这也使得您更容易限制所做的查询，让我们以收银机为例。他们不需要知道生产日期，但也许有人在后台用手持式扫描仪就能知道

// my mysql is a bit rusty, but here is an example

// cash register
SELECT 
    items.id, items.name, 
    items_prices.sell_price,
    items_sales.sale_price
FROM items
JOIN items_prices ON items.id=items_prices.items_id
JOIN items_sales ON items.id=items_sales.items_id

手持扫描仪的人需要不同的信息，而控制这些信息还有其他方法一些数据库可以让你控制它购买访问它们的用户。当与第三方合作时，或者仅仅是个人混合和匹配查询时，这会使它变得更加容易

你甚至可以进行更深入的研究，但有一点是，它只是为你从中得到的很少的东西创造了更多的工作。不确定这是否有帮助，但这是我使用数据库的经验