在数据库中使用继承来减少以后更改模式的痛苦，这是不好的做法吗？

Question

我正在考虑数据库的新设计。并且我想在数据库中使用Table-Per-Type继承。我希望将审计数据(如创建|修改日期、user_id、权限等)与实际数据分开，并使用一些抽象对象(表)，但我不打算继承超过3个(使事情简单快捷)。这样做的原因是我希望我的数据库设计是灵活的，易于修改，而不会对我的代码产生太大的影响。以这种方式使用继承和扩展现有功能对我来说是一个很好的选择。

我读过一些帖子，说在数据库中使用继承是不好的做法，但我从来没有看到关于这一点的解释，也没有看到具体会发生什么问题。

Answer 1

作为对我自己问题的回答:我重读了Martin Fowler的关于数据库继承的《企业应用程序架构的模式》一书。它帮助我理清思路，选择我的继承策略。在数据库中使用继承并不是坏事，正如S.Lott所说，这需要彻底的思考和测试。

Answer 2

我希望我的数据库设计是灵活的，易于修改，不会对我的代码产生太大的影响。

首先，您只是在描述对象关系映射(ORM)。您需要更新问题以指定语言、数据库和ORM。

其次，这种灵活性通常是一个吸引人的麻烦。

您没有指定您正在使用的数据库，但是您的需求中可能存在根本的矛盾。

SQL数据库具有相对固定的、不太灵活的模式，因此它可以很快。

要求灵活性意味着您现在必须以“灵活性”的名义对数据库进行某些相对痛苦和复杂的更改。涉及移动(可能是标准化)数据的表设计更改可能是痛苦和困难的，因为数据库通常不是为灵活性而设计的。

然而，更重要的是，不存在从继承属性到数据库表的简单映射。

有时需要将超类属性复制到多个表中。

然而，有时超类属性应该是一个单独的表，并显式地连接到子类表。

当您阅读更多关于ORM的内容时，您会发现这是一个非常复杂的问题。它需要思考，每个设计决策都有重要的后果。

没有“包罗万象”的解决方案。你的模棱两可的“我想在数据库中使用每个类型的表继承”既不是好主意，也不是坏主意。这是一个模糊的想法。每个单独的表和每个单独的继承决策必须分别基于性能要求和预期的灵活性需求。