在数据库中使用继承来减少更改模式的痛苦是一种不好的做法吗？
我正在考虑数据库的新设计。我想在数据库内使用每个类型的表继承。我想将审计数据（如创建|修改日期、 user_id 、权限等）与实际数据分开，并使用一些抽象对象（表），但我不打算拥有超过 3 个继承（以使事情变得简单快速）。这样做的原因是我希望我的数据库设计灵活且易于修改，而不会对我的代码产生太大影响。对我来说，使用继承和扩展现有功能看起来是一个不错的选择。
我读过一些文章，指出在数据库中使用继承是不好的做法，但我从未见过对此的解释以及可能发生的确切问题。
I'm thinking on new design for database. And I want to use Table-Per-Type inheritance inside database. I want to separate audit data (like create|modify dates, user_id , permissions,etc) from actual data, and use some abstract objects(tables) but I don't plan to have deeper than 3 inheritance (to make things simple and fast). The reasons for this I want my database design to be flexible, and easy to modify, without lots of impact on my code. And using inheritance and extending existing functionality that way looks like a good choice to me.
I read some posts that using inheritance in database is bad practice, but I never seen explanation of that and what exact problems can occur.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，您只是描述对象关系映射 (ORM)。您需要更新您的问题以指定语言、数据库和 ORM。
其次，这种灵活性往往是一种有吸引力的麻烦。
您没有指定您正在使用的数据库，但您的愿望可能存在根本矛盾。
SQL 数据库具有相对固定、不太灵活的模式，因此它可以很快。
要求灵活性意味着您现在必须以“灵活性”的名义对数据库进行某些相对痛苦且复杂的更改。涉及移动（并可能规范化）数据的表设计更改可能会很痛苦且困难，因为数据库通常不是为灵活性而设计的。
然而，更重要的是，没有从继承属性到数据库表的简单映射。
有时应将超类属性复制到多个表中。
然而，有时超类属性应该是一个单独的表，并显式连接到子类表。
当您阅读有关 ORM 的更多内容时，您会发现这是一个非常复杂的问题。它需要思考，每个设计决策都会产生重要的后果。
不存在“一揽子”解决方案。您模糊的“我想在数据库内使用每个类型的表继承”不是一个好主意或坏主意。这是一个模糊的想法。每个单独的表和每个单独的继承决策都必须根据性能要求和预期的灵活性需求单独做出。
First, you're just describing Object-Relational Mapping (ORM). You need to update your question to specify a language, and a database and an ORM.
Second, this kind of flexibility is often an attractive nuisance.
You don't specify what database you're using, but there can be a fundamental contradiction in your desires.
A SQL database has a relatively fixed, less-than-perfectly-flexible schema so that it can be fast.
Asking for flexibility means you must now make certain kinds of relatively painful and complex changes to the database in the name of "flexibility". Table design changes that involve moving (and possibly normalizing) data can be painful and difficult because the database isn't generally designed for flexibility.
More importantly, however, there's no simple mapping from inherited attributes to database tables.
There are times when superclass attributes should be copied into multiple tables.
However, there are also times when the superclass attributes should be a separate table with an explicit join to the subclass tables.
As you read more about ORM's, you'll see that this is a problem of non-trivial complexity. It requires thinking, and each design decision has important consequences.
There is no "blanket" solution. Your vague "And I want to use Table-Per-Type inheritance inside database" isn't a good idea or a bad idea. It's a vague idea. Each individual table and each individual inheritance decision must be made individually based on performance requirements and the expected need for flexibility.
作为我自己问题的答案：我重读了 Martin Fowler 的有关数据库继承的企业应用程序架构模式一书。这也帮助我理清了思路，选择了继承策略。在数据库中使用继承并没有什么坏处，正如 S.Lott 所说，这需要彻底的思考和测试。
As an answer to my own question: I have reread Martin Fowler's book patterns of enterprise application architecture about database inheritance. And it helped me to clear my thought and choose my inheritance strategy. Nothing bad in using inheritance in database, and as S.Lott said, this requires thorough thinking and testing.