在多对多通过连接表中,has_many / through 是可选的吗?
我有 3 个模型:客户、商店、注册(邮件列表)
(注册是它们自己的对象,因为它们具有选择加入、选择退出、列入黑名单等状态)
客户和商店相当独立,目前彼此没有直接关联其他。
然而,我们正在添加一个“邮件列表”结构,注册:
Signup belongs_to :store AND :customer
Store has_many :signups
Customer has_many :signups
我不清楚在什么条件下我需要包括:
store has_many :customers, :through => :signups
customer has_many :stores, :through => :signups
如果商店 X 向其邮件列表发送广播电子邮件时没有 :through,我们只需let mail_list =customers.signup.find( where store_id matches X)
问题 1:这种方法有什么问题吗?
问题 2:如果我们确实添加了 :through,那么查询会是什么样子来获取所有在当前商店“注册”的客户?
问题 3:如果我们在客户和商店之间有 3 或 3 个不同的联合表(例如订单、发票、注册、折扣俱乐部),这会带来任何问题吗?
I have 3 models: Customers, Stores, Signups (a mailing list)
(Signups are their own object since they have state like opted in, opted out, blacklisted, etc)
Customers and Stores are fairly independent and currently have no direct association to each other.
However, we're adding a 'mailing list' construct, Signups:
Signup belongs_to :store AND :customer
Store has_many :signups
Customer has_many :signups
It's not clear to me under what conditions I would need to include:
store has_many :customers, :through => :signups
customer has_many :stores, :through => :signups
Without the :through when a store X sends a broadcast email to it's mailing list, we'd simply let mail_list = customers.signup.find( where store_id matches X)
Question 1: Is there any problem with that approach?
Question 2: if we DID add the :through, what would the query looks like to get all the customers who have a 'signup' for the current store?
Question 3: if we had 3 or 3 different joint tables between customers and stores (for example orders, invoices, signups, discountclubs) does that present any problem?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您给出的示例不起作用(非 :through 方法),因为如果客户有很多注册,则
customer.signup
将仅在客户实例上可用,而不是在集合上可用。如果您不使用联接表,则必须迭代大量数据来收集所有内容,或者编写一些 sql 来处理它,这意味着无论如何您都在使用联接表,但效率低下。store.customers
会生成如下内容:不,这应该不是问题。这是处理此类关系的正确日子(好吧,也许不是订单和发票,除非它们是多个客户或其他东西所共有的)。只要确保将索引放在正确的列上即可。
The example you've given wouldn't work (the non :through approach) because if customers have many signups,
customer.signup
will only be available on a customer instance, not a collection. If you were to not use join tables, you'd have to either iterate over a lot of data to collect everything, or write some sql to deal with it, which means you're pretty much using a join table anyway, but inefficiently.store.customers
would generate something along these lines:No, it shouldn't be a problem. It's the right day to deal with those kind of relationships (well, maybe not orders and invoices unless they're common to multiple customers or something). Just make sure you put indexes on the right columns.