我陷入了一个奇怪的设计问题，
我正在研究两种类型的配置文件模型，
这两种 Profile 的典型 OO 行为是相同的，但只有重要的属性/属性是共同的（非常重要的 5-6 个），其他属性如“兴趣等”（几乎 10-15 个属性）没有机器人配置文件
早先从事此工作的编码人员为机器人配置文件/用户配置文件创建了单独的模型/控制器，这在任何地方都会产生大量冗余，并且正如预期的那样难以维护、编写测试等。我想把它干掉，至少可以解决部分/全部这些冗余问题。
有人建议将单表继承作为解决方案
有人建议改用多态关联。
什么是更好的方法。我们什么时候真正使用 STI？
我自己的想法是，当模型的属性相同且行为不同时，最好使用 STI。
想想我能做什么？
【问题讨论】：
我已经写了一篇关于这个主题的文章，包括一些使用 STI 的技巧：
Single Table Inheritance in Rails
简而言之：对象之间需要有清晰的 OO 风格的继承关系（正如 womble 雄辩地指出的那样），而不仅仅是一些共享数据。如果没有自然而明显的类层次结构，STI 设计可能会随着应用程序的发展而变得难以维护。
其次，您应该考虑将所有数据放在一个表中是否重要。使用多态关联，您的数据库查询将变得更加复杂，并且可能更慢。如果您打算将网站上的所有对象一起列出（例如，在表格中），那么 STI 可能是您的最佳选择。
第三，确保您的子类没有太多独特的属性。将所有数据放在一个表中，您不需要很多非全局列。这些不仅占用空间（不是主要问题），而且使数据结构混乱。如果确实有“特殊”列，则应在代码中明确说明。
最后，如果您确实使用 STI，我强烈建议您为所有子模型使用一个控制器。控制器的主要功能是提供对对象的访问，如果需要以非常不同的方式访问对象，那么 STI 可能一开始就不是正确的设计选择。
查看我的文章（上面的链接）了解更多有用的提示。
【讨论】：
Rails STI 的一个问题 - 大多数插件（等等）并不完全支持它。您会发现自己修补了许多常见问题。
【讨论】：
我可能会使用 STI 或根本不使用特殊功能。您可能可以将所有内容称为个人资料，并且如果其用户为零，您就会知道它是否是“机器人”。您也可以在不使用 STI 的情况下存储“类型”字段。
某些事情会影响我使用 STI 的决定：
避免 STI 的原因有时是它会妨碍您。例如，将对象从一种类型更改为另一种类型（在这种情况下是 Bot 到 Profile）可能会非常烦人。有时一个简单的“类型”字段会更好。
值得注意的是，如果您使用 STI，您可能需要一个通用的基类。所以你可能想要Profile、BotProfile和UserProfile。名字由你决定。 :)
【讨论】：
当属性相同但行为不同时，将 STI 表征为最有用的是“大约正确”，但可能有点限制。顾名思义，当存在明确的 OO 风格的继承关系，而不是不同类型的对象之间的数据库风格的关系时，我喜欢使用 STI。
如果机器人和用户之间有共同的代码，我会说 STI 听起来像是赢家。如果只有一些共同的属性，它可能不太适用，但仍然值得一试。
我是一个很有实验精神的人，所以我的建议是尝试一下。分支您的代码并将模型重构为 STI 关系。看看它是否真的把事情搞砸了，或者只是将一组令人头疼的问题换成了其他问题。
我认为你不会从中看到太多好处的一件事是让你的控制器干涸。根据我的经验，STI 模型通常不会转化为类似的相关控制器。但这将是另一种尝试。有时会赢，有时不会。
【讨论】：