Question

我有一家Magento商店（使用MySql db），只是注意到一些开发人员引入了一个自定义db来捕获某些结构化数据。

现在，我注意到这些表不是通过外键相互链接的，而是添加了一个列，例如priceListID = 01124与价格表上的Id相同。因此，将数据链接在一起必须在代码中通过触发我假设的不同选择语句来完成。

现在我想知道是否需要尽快解决此问题，或者是否可以在数据库级别上不使用外键将数据链接在一起？这样做的弊端是什么，也许有一些好处（例如灵活性？）

希望您可以帮助我！非常感谢！

Answer 1

从您的描述中，我了解到表确实是功能相关的，因为它们共享一条共同的信息（新表中的priceListID与表中的id相关）原始表格）。一方面，这种设置仍然允许编写将表连接在一起的查询。

但是，不创建外键来表示该关系的缺点是，从数据库角度来看，不能保证该关系的一致性。例如，有可能在新表中创建记录，而原始表中不存在priceListID。在新表中存在相关记录的同时，还可以删除旧表中的记录，从而将孩子变成孤儿。

结论是：通过不使用外键，开发人员仅依靠应用程序来维护数据完整性。不使用RDBMS提供的内置功能来保护数据一致性并没有明显的好处，而且开发人员很可能只是忘记了表定义的关键部分。我建议与他们进行交谈，并让他们联系以创建丢失的外键（除非他们可以给出清楚的解释，为什么不这样做）。

这应该很简单：

ALTER TABLE newtable
    ADD CONSTRAINT fk_new_to_original_fk 
    FOREIGN KEY (priceListID ) 
    REFERENCES originaltable(id);

请注意，这要求引用列中的所有值在父表中均可用。

Answer 2

将这样的约束保留在数据库中几乎没有什么好处：

性能。如果将大多数约束（例如外键）存储在靠近数据的数据库中，则可以更好地实现。您是否要使用其他select检查数据完整性？您必须对数据库进行额外的请求。需要一些时间。
如果您有多个与数据库一起使用的应用程序怎么办？您必须编写代码来检查所有数据的完整性，这意味着需要额外的费用。
同步。当您通过其他选择检查数据完整性时，其他一些用户可能会同时删除此数据。而且您不会知道。当然，可以正确地执行这些检查，但这仍然是您要做的额外工作。

对我来说，这都是不好的感觉，不是可扩展的设计，可能带来很多问题。数据完整性是建立数据库的目的。这些类型的验证应保留在数据库中。