Mysql 如何使用不同的列和ID链接包含相同产品的多个表

我有许多来自不同供应商的表格，其中包含他们提供的产品信息。表格的格式是不同的ID、不同的描述等，因为每个供应商存储关于其产品的单独信息。不同表中的某些产品可能是相同的，但我不知道在插入行的时候；我必须手动检查它们，以确定哪些产品是相同的

例如，考虑下面的表（）：

每个表可能有不同的ID值、列，甚至同一列的值；e、 g:

Table A:
+------------+-----------------+---------------+-----------------+
|         ID |            NAME |         COLOR |          WEIGHT |
+------------+-----------------+---------------+-----------------+
| RFY-55-001 |  Wagon, Classic |           Red | 15.199999809265 |
| RFY-62-001 | Trike, My First |           Red |   8.60000038147 |
| RFY-64-001 |  Trike, 12 Inch |           Red |  15.39999961853 |
| SWN-35-001 | Trike, Roadster | Metallic Blue | 20.700000762939 |
| SWN-35-002 | Trike, Roadster |        Silver | 20.700000762939 |
| SWN-35-003 | Trike, Roadster |    Cherry Red | 20.700000762939 |
+------------+-----------------+---------------+-----------------+

Table B:
+-------+--------------------------------------------+--------+
|    ID |                                       NAME |  COLOR |
+-------+--------------------------------------------+--------+
| 10560 |                  Schwinn Roadster Tricycle |    BLU |
| 10685 |              Radio Flyer Classic Red Wagon | (null) |
| 10880 | Radio Flyer Classic Red Dual Deck Tricycle | (null) |
| 12008 |         Fisher-Price I Can Play Basketball | (null) |
+-------+--------------------------------------------+--------+

供应商A存储简短的产品名称，但在附加列中包含详细的产品信息。供应商B存储了更详细的产品名称，但没有太多附加信息。在这两种情况下，制造商的身份被混入其他领域

行是自动插入的，在插入前我无法检查每个产品。我只能偶尔浏览一下，然后手动更新找到的链接。例如，一项小小的研究表明，Radio Flyer Classic红色双层三轮车的前轮为12英寸，重量为15.4磅，这表明表a中的项目

RFY-64-001

与表B中的项目

10880

是同一产品

如果不同表中的行引用同一产品，在插入后的某个时间，我会使用什么关系来“链接”这些行，以便每个独特的产品都有一个键？

---

显而易见的解决方案是添加一个带有“我的键”的连接表，并在插入到其他表时使用触发器。此解决方案的问题是“同步”过程变得非常手动，并且容易出错。

好的；因此您有许多表来自不同的源，每个表实现相同的实体（产品）具有自己的逻辑结构。任何给定的记录可能存在于多个表中，您的任务是协调这些不同的数据源，使用一些手动过程来确定表中哪些记录相似/相同

这听起来类似于我们在加州大学/环境保护局（Cal/EPA）所经历的一个过程，即在创建全州空气污染清单时协调来自许多不同来源的数据。这些来源包括几个不同的建模团队，每个团队都使用一组不同的输入和输出参数；来自监测站的直接测量；来自m地方和市政机构；在某些情况下，个人和企业直接向我们报告的数据。这些数据以许多不同的格式提供给我们，其中很多是重叠的

我不会让你厌烦我们和解过程的细节，但我可以告诉你一些我从中学到的东西，并建议一种可能对你有用的方法

首先，将存在于许多不同格式中的重叠数据放在一起很糟糕。如果每个人都使用相同的表结构，彼此不干涉，我们的工作就会轻松得多。也就是说，这是我们必须处理的现实；这就是为什么我们有工作的原因。不同的组织和个人运作方式不同，而且大多数时候你没有权力改变它们的运作方式

你需要一个计划，否则错误将不是偶然的错误，而是经常发生的错误。你可以采取的一个广泛的方法是：我将接受来自所有这些来源的数据，以所有这些格式，并将其放入一个暂存数据库，在那里我将根据需要操纵、聚合、剪切、删除和破坏数据，以便将其放入我的数据库中-在一个只有一个物理模型的数据库中，一切都很美好。然后我可以忘记我对数据所做的所有难以言喻的事情，以便首先将数据放入其中，生活将变得美好……直到我不得不重新做一遍。这被称为ETL，它代表提取、转换、加载-或者可能是诱捕、折磨、切除脑叶，取决于你玩得有多开心。如果你喜欢，你可以（或者，或者，或者）

关于ETL的好处在于，你最终会找到一个感觉良好的地方。关于ETL，不太好的地方在于，通过转换数据以满足你的特定需求，你经常会丢失源中存在的某种程度的细节或实用性。另一方面，如果你创建一个高度通用化的数据模型来捕获其中的大部分内容尽可能地源数据并避免破坏性的转换，您最终会得到一个高度通用的数据模型，这意味着需要更多的文档和维护工作，即使您的模型从未如此完美

现在，听起来你要么不愿意，要么无法转换源数据以适应一个合理集中的模型。而且你不应该把所有的数据都塞进一个满是重复列和空值的表中，以免你迅速陷入疯狂的过程中被克图鲁在R'lyeh家中的景象打断：

+-----+---------+------------+---------+-----------------+-------------+-----+
| id  | sup1_id | sup1_color | sup2_id | sup2_color      | sup2_weight | ... |
+-----+---------+------------+---------+-----------------+-------------+-----+
| 1   | 7124    | brn        | 93      | Burnt Sienna    | 0.65        | ... |
| 2   | 415     | yel        | 8552    | Bananas Foster  | 12.50       | ... |
| 3   | NULL    | NULL       | 51      | Mostly Red      | 2.00        | ... |
| 4   | 159     | wht        | NULL    | NULL            | NULL        | ... |
| 5   | NULL    | NULL       | NULL    | NULL            | NULL        | NULL NULLNULLNULLUNNLUNUL gratuitous Unicode diacritics, you get the idea

这根本不属于关系数据库；它是一个平面文件/电子表格范例，应该限制在非数据库环境中，如Excel。（或Access.Zing！）

如果您需要以各种形式保留不同的表，但仍然希望将它们彼此关联并保留某种“主”记录，那么剩下的就是创建其他表来描述这些关系，并存储“一个键来管理它们”。“现在我们正朝着谈论子类型和角色的方向前进。您有一个实体（产品），以各种方式表示；如果产品的每个实例仅存在于一个表示中，那么您正在处理实体子类型。在存在重叠的情况下，如此处所示，最好考虑实例可以与每个供应商承担的角色。下面是一个例子：

你的“主人”身份证和任何

+-----+---------+------------+---------+-----------------+-------------+-----+
| id  | sup1_id | sup1_color | sup2_id | sup2_color      | sup2_weight | ... |
+-----+---------+------------+---------+-----------------+-------------+-----+
| 1   | 7124    | brn        | 93      | Burnt Sienna    | 0.65        | ... |
| 2   | 415     | yel        | 8552    | Bananas Foster  | 12.50       | ... |
| 3   | NULL    | NULL       | 51      | Mostly Red      | 2.00        | ... |
| 4   | 159     | wht        | NULL    | NULL            | NULL        | ... |
| 5   | NULL    | NULL       | NULL    | NULL            | NULL        | NULL NULLNULLNULLUNNLUNUL gratuitous Unicode diacritics, you get the idea

create table product_master (
product_id INTEGER(11) NOT NULL AUTO_INCREMENT,
product_name varchar(512),
...
);

alter table a add product_id integer(11);
alter table b add product_id integer(11);
...