手机账单建模：我应该使用单表继承还是多态关联？
在我的域中：
- 用户有许多账单
- 账单有许多账单项目（因此用户通过账单拥有许多账单项目）
- 每个账单项目都是以下之一：
- 致电
- SMS（短信）
- MMS（彩信）
- 数据
以下是每个单独 BillItem 的属性（有些是常见的）：
替代文本 http://dl.dropbox.com/u/2792776/screenshots/2010-04-13_2146-1.png
我的问题是我是否应该使用单表继承（即一个带有“type”列的“bill_items”表）或多态性（每个 BillItem 类型都有单独的表）来建模这种安排，以及为什么。
In my domain:
- Users have many Bills
- Bills have many BillItems (and therefore Users have many BillItems through Bills)
- Every BillItem is one of:
- Call
- SMS (text message)
- MMS (multimedia message)
- Data
Here are the properties of each individual BillItem (some are common):
alt text http://dl.dropbox.com/u/2792776/screenshots/2010-04-13_2146-1.png
My question is whether I should model this arrangement with single-table inheritance (i.e., one "bill_items" table with a "type" column) or polymorphism (separate tables for each BillItem type), and why.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会选择多态关联，因为已经有足够的字段不适用于所有/大多数项目。 STI 只会浪费大量空间，但如果忽略优化，它也是一个非常严格的设计，因为当需要更多字段时，扩展该设计的最自然方法是将它们添加到表中。
另一方面，多态关联仅指定所有实现者必须遵守的契约。在这种情况下，合同仅规定某个项目必须是可计费的，并允许每种类型的项目独立发展。如果这些不同的类之间需要共享逻辑，那么最好将其转换为模块并包含它。
I would go with a Polymorphic association as there are enough fields already that don't apply to all/most of the items. STI will just waste a lot of space, but ignoring optimization, it's also a very rigid design as the most natural way to extend on that design when more fields are required will be to add them to the table.
Polymorphic association on the other hand only specifies a contract that all implementors must follow. In this case the contract only says that an item must be billable, and allows each individual type of item to evolve independently. If there is logic to be shared among these different classes, it might be better to just convert it into a module and include that.