Ruby on rails Rails中资产单表继承的优缺点

我正在研究文件上传gems，似乎有一种趋势，就是将所有资产放在一个“资产”表中，并使用STI对它们进行子类化。如

ImageAsset

，

VideoAsset

，

AudioAsset

等

我是Rails新手，从未使用过STI。以前我只会制作

图像

，

视频

，

音频

单独的表格。当然，他们可能会共享一些列，但我认为他们也会有一些不同的列（例如，采样率不适用于图像）

将所有这些都塞进一个“资产”表的好处是：更容易对所有资产运行查询。缺点：桌子会更快变大。如果有问题的话，我想我可以在“类型”栏上切分。此外，我预计所有的音频列将是空的图像行等

---

我的整个应用程序都将以资产为基础，所以我想在做出决定之前，确保我清楚地知道利弊。有没有人做过STI资产并为此感到后悔？有没有人这样做而不后悔（为了一大笔资产）？CTI（类表继承）会是一个更好的解决方案吗？

我想说，使用STI的最大缺点之一是，如果您在表中添加了一列，而该列在STI的所有模型之间都不共享（这意味着相同的事情），那么您就破坏了数据的完整性

（关系）数据库中的空字段通常会导致比它们解决的问题更多的问题

我已经被这个问题困扰了好几次，尤其是当STI关系中的类开始拥有自己的子类时，这会让人感到沮丧，而子类又会向表中添加更多的列

我想说，如果你想使这个结构尽可能好，我真的认为CTI是一个更好的选择，即使它可能有点棘手，让它与rails一起工作。至少比STI要复杂得多

在我的脑海中，我可以想到一个场景，在这个场景中，STI可能实际上是合理的，那就是当你处理交易模型时（例如从银行账户的存款和取款等等）。在这些情况下，除了交易的“方向”之外，两种模型基本上是相同的

---

也可以说STI对于快速原型设计来说是“好的”，如果你只是想快速组合一些东西，看看它是否有效，你可以使用STI，但是一旦你开始添加对关系中的所有模型都没有意义的列，您可能应该将其重构为CTI或其他东西。

问题在于原型有一种恼人的习惯，即在没有建议的重新架构等情况下，就变成真正的“任务关键型”应用程序。我倾向于认为STI几乎总是一个错误，你不应该用沙子打地基。@muistoshort我知道那个故事！从逻辑上讲，这可能是一个艰难的改变，使繁忙的网站与大表。否则，STI=>CTI看起来确实是一个非常直接的变化？我倾向于使用STI，因为似乎没有一个好的、强大的CTI解决方案。此外，我的查询主要是在“基类”上，仅在呈现视图时才进行专门化（例如，当type==video时使用

，当type==image时使用

，等等）。我想和Tumblr的帖子没什么不同。此外，我想存储用户定义的订单（想想jQuery sortable），我想这可能会更简单一些。我还是很烦。如果这些不是持久化对象，我将避免继承。我会让他们实现一个公共接口。例如，他们可能都对

\url

做出响应。而且，要处理混合类型资产的“手工排序集合”，没问题，这只不过是Ruby中的数组问题。Martin为了避免空列问题，您如何看待子类属性带有PostgreSQL hstore列的STI？这并不适合所有的情况，但我认为它对我来说是可以的。如果您不熟悉hstore，那么它是一种hashmap/键值列类型，您可以对其进行索引和查询。我相信Rails甚至还反序列化了hstore列。@aspect听起来确实稍微好一点，但无论如何我可能都会避免使用STI。这可能是因为我感觉到了它可能造成的痛苦（当时我的老板告诉我我们没有时间对它进行适当的重构）。正如mu太短所说，原型往往会变成任务关键型，这是不好的。当它们含有STI时，它们通常只是等待爆炸的炸弹。