database - 何时拆分到另一个数据库表

Question

我的问题是关于数据库以及何时拆分为其他表。我正在为多个平台制作库存跟踪器。例如，我有一个Item资源，我将连接到不同的平台，比如 Foo 和 Bar 有Items。有名称、数量、sku、条形码等共享属性，但平台具有特定于它们的不同属性。他们将有自己的唯一 ID，Foo 可能有标签，而 Bar 可能没有但有供应商标签。现在我所做的是这样的：

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

但是如果我与 Bar 平台集成，我是否应该在Item资源中添加字段，例如bar_id, bar_vendor, bar_other_properties？还是应该将其创建为另一个表，并且 Item 将具有该表的外键？我什么时候应该将这些特定于平台的属性拆分到另一个表中？性能方面，额外的连接是否会使事情变慢？例如，如果我要为用户更新所有这些项目，我将加入User、Shop、Item，现在可能加入PlatformSpecificItemData，并且我不知道是否存在要加入的表过多并影响性能的点。

标签： databasedatabase-design

Answer 1

老实说，这有时可能很难。我经常使用数据库，但它们很少真的那么大，不像行中那么大，但在字段中那么大。通常是 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

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

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