父记录中的多个外键 (Rails)
我正在尝试摆脱连接表，转而采用对于大型数据集更快的数据库设计。我计划执行此操作的方法是将孩子的 id 存储在父记录中。 像这样：
父母表：
id, child1_id, child2_id, child3_id,... child(100)_id
子表：
id、grandchild1_id、grandchild2_id、...grandchild(100)_id
型号：
家长
has_many：孩子，：依赖=> ：摧毁
Accepts_nested_attributes_for :children
儿童
属于：父级 has_many：孙子，：依赖=> ：摧毁
接受嵌套属性：孙子
孙子
own_to :child
我的最终结果是能够以相同的形式编辑父项、子项和孙项。通过使用连接表已经可以做到这一点，但我热衷于提高性能
当我依赖连接表提供的功能时，如何才能使我的数据库获得更好的性能？ 请帮忙，我已经在网上搜索很多天了：/谢谢！
I'm trying to get rid of my join tables, in favor of a database design that is faster for large datasets. The way I'm planning to do this is to store the id's of children in the parent record.
Like so:
Parents table:
id, child1_id, child2_id, child3_id,... child(100)_id
Children table:
id, grandchild1_id, grandchild2_id,... grandchild(100)_id
models:
Parent
has_many :children, :dependent => :destroy
accepts_nested_attributes_for :children
Child
belongs_to :parent
has_many :grandchildren, :dependent => :destroy
accepts_nested_attributes_for :grandchildren
Grandchild
belongs_to :child
My end result would be to be able to edit parent, children and grandchildren in the same form. This is already possible by using join tables, but I'm keen on boosting up performance
How can I get better performance for my database, when I depend on the functionality join tables provides?
Please help, I've been searching the web for many days now :/ Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是糟糕的数据库设计。如果父母有超过 100 个孩子怎么办？
3个建议：
考虑使用NOSQL数据库存储。
也许使用acts_as_tree。
你不能这样规范化它吗：
Parent：id
Child：id，parent_id
Grandchild：id，child_id
This is terrible database design. What if a parent has more than 100 children?
3 suggestions:
Consider using NOSQL database store.
Perhaps use acts_as_tree.
Could you not normalize it as such:
Parent: id
Child: id, parent_id
Grandchild: id, child_id
您确定性能有问题吗？如果您只是进行预测，那么您可能会进行过早的优化。
如果您能够创建与子级数量一样多的列，那么我几乎可以肯定您试图避免的数据库设计不是问题。只需确保数据库有正确的索引即可。
一个工作的（并被测试覆盖的）应用程序是考虑性能的一个很好的起点。您可能会注意到，使用最简单的方法性能是可以接受的。
Are you sure you have a problem with performance? If you are only anticipating, you may be doing premature optimization.
If you are able to create this many columns as the number of children, then I am almost sure that the database design which you are trying to avoid, is not the problem. Just ensure that the database has proper indexes.
A working (and covered by tests) application is a good starting point for thinking about performance. It may happen that you notice that the performance is acceptable with the simplest approach.