Rails，我是否错误地认为多态关联被高估、限制和不必要？
好的，所以我一直在尝试用不同的方式来组织有关 STI 和多态关联的 Rails 3 应用程序。我试图找到一种既易于编码又易于使用的方法，并且最有可能与未来的更改最兼容。在阅读了大量可选的（通常缺乏且写得不好）文章之后，我得出了自己的一些结论。
首先，使用 STI 似乎是最安全的选择，因为它易于编码、易于阅读和使用，并且易于应对任何未来的更改而无需太多重写。我能看到的唯一合理的缺点是，在您的数据库中，数据中会有“漏洞”。有些人认为这是一件坏事。但是，恕我直言，如果这是唯一的缺点，而结果是让你的余生变得更加轻松，那么谁在乎呢？
其次，看来多态关联确实只在某些情况下才能很好地工作，而不是在所有情况下都有效。此外，似乎在任何可以使用多态关联的情况下，您也可以只使用 STI（而不是相反）。那么为什么还要费心多态关联呢？只是为了从数据库中清除那些讨厌的“漏洞”？但是，您会添加看起来非常相似的重复字段和额外表，更不用说多组控制器、模型和视图等。
第三，即使您确实确定了使用多态关联的适当时间，并正确实现了它，事情可能会发生变化，你会发现自己不得不放弃多态性的东西并最终实现 STI。我不认为这种情况会以相反的方式发生。 STI 似乎可以很好地适应任何设置，而多态关联似乎需要“恰到好处”才能像宣传的那样工作。
现在，我不是最聪明的人，所以这些可能是错误的和/或短视的观察 - 如果您认为我错了，请告诉我，并尝试提供一些好的证据来支持您的案例！
OK, so I've been toying with different ways of organizing my Rails 3 apps regarding STI and Polymorphic Associations. I was trying to find a way that is both easy to code, and easy to use, and has the highest chance of being the most compatible with any future changes. After alot of reading a lot of optionated (and often lacking and poorly written) articles, I've come to some conclusions of my own.
First, it seems that using STI is the safest bet, in terms of being easy to code, easy to read and use, and easy to work with any future changes without too much re-writing. The only legitimate downside I can see is that in your DB there will be "holes" in the data. Some ppl think that this is a bad thing. But, IMHO, if this is the only downside and the upshot is making the rest of your life a hell of a lot easier, then WHO CARES?
Second, it seems that Polymorphic Associations really only work nicely in certain situations, definitely not ALL situations. Moreover, it seems that any situation where you COULD use Polymorphic Associations, you could also just use STI (and not the other way around ). So why bother with Polymorphic Associations at all? Just to get those pesky "holes" out of your DB? But then you are adding duplicated fields and extra tables that look an awful lot alike, not to mention multiple sets of controllers and models and views etc.
Third, even if you do identify a proper time to use Polymorphic Associations, and properly implement it, things could change and you would find yourself having to rip out the Polymorphic stuff and end up implementing STI anyways. I'm not seeing a time when this would happen the other way around. STI seems to play nice with any setup, whereas Polymorphic Associations seem to need things to be "just so" in order to work as advertised.
Now, I'm not the smartest guy, so these could be wrong-headed and/or short-sighted observations - Please let me know if you think I am wrong, and try to provide some good evidence to support your case!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果我要把你的论点推向最远的结论，我会得到这样的结论：为什么还要费心拥有多个数据库表呢？只需使用一张表和 STI 即可存储您的所有数据。
此外，考虑一个包含作者、出版商、书籍和用户的书店应用程序。想象一下，用户可以选择订阅电子邮件通知，以了解任何作者、书籍或出版商的更改。为此，可以创建一个
通知表。该表希望与任何可以遵循的对象具有多态关联。您将如何利用 STI 以更简洁的方式构建它？If I was to take your argument to its furthest conclusion I would get something like: why even bother with having multiple database tables? Just use one table and STI to store all your data.
Additionally, consider a bookstore application with authors, publishers, books and users. Imagine that there is an option for a user to subscribe to email notifications for changes to any of authors, books, or publishers. To do this, one might create a
notificationstable. This table would want to have a polymorphic association to any of the objects that can be followed. How would you structure that in a cleaner way with STI?