诗歌rails之Association之魔法
Association魔法
先来看看什么是association，以及association如何使你的代码更加简单和优美。
举个rubyonrails guides上的例子。
一个customer有很多orders，它们的模型是这样子的：
- class Customer < ActiveRecord::Base
- end
- class Order < ActiveRecord::Base
- end
假如要创建一个属于一个customer的order，则需要：
- @order = Order.create(:order_date => Time.now, :customer_id => @customer.id)
或者删除一个customer，以及他的所有orders：
- @orders = Order.find_by_customer_id(@customer.id)
- @orders.each do |order|
- order.destroy
- end
- @customer.destroy
这样的代码是非常繁琐的，并且在语义上很不清晰。让我们为这两个模型声明association：
- class Customer < ActiveRecord::Base
- has_many :orders, :dependent => :destroy
- end
- class Order < ActiveRecord::Base
- belongs_to :customer
- end
当我们为这两个模型声明了association之后，一切就变得简单和明了了：
- @order = @customer.orders.create(:order_date => Time.now)
- @customer.destroy
这就是assciation的魔法。
选择正确的association
使用何种association，跟数据库schema的设计有关；但最重要的，是反之，在设计数据库schema的时候，要考虑到数据的真正含义。
比如，一个company，它拥有一个account，这是明显的account从属于company的关系。
那么，它们的模型和association声明最好应该是这样的，以便跟语义匹配：
- class Company
- has_one :account
- end
- class Account
- belongs_to :company
- end
但association的声明，还得符合数据库的表结构（特别是建立在一个遗留数据库上的时候）。这时候的外键（foreign key）应该在accounts表上，而不是companies表上。
又比如，一个teacher有很多students，同时一个students也有很多teachers。所以，它们应该是多对多的关系，那么，association的模型声明应该是这样的：
- class Teacher
- has_and_belongs_to_many :students
- end
- class Student
- has_and_belongs_to_many :teachers
- end
这种多对多的映射，在数据库上需要有一个中间表：students_teachers。但有时候，我们希望这个中间表变得有意义起来，而不是纯粹起到关联作用，比如在它上面添加一些其它字段。并且希望这个中间表的名字更加有意义，以便映射到一个模型。这时候，需要使用另外一种association，来建立这三个模型之间的关联：
- class Teacher
- has_many :relations
- has_many :students, :through => :relations
- end
- class Relation
- belongs_to :teacher
- belongs_to :student
- end
- class Student
- has_many :relations
- has_many :teachers, :through => :relations
- end
还有一种高阶用法，有时候，我们希望一个模型属于几种不同的其它模型。比如，image即属于一个lightbox，也属于一个shopping cart。那我们可以使用多态association（polymorphic association ）：
- class Image
- belongs_to :image_collection, :polymorphic => true
- end
- class Lightbox
- has_many :images, :as => :image_collection
- end
- class ShoppingCart
- has_many :images, :as => :image_collection
- end
同时，在做migration的时候，也要注意声明这是一种多态的关联：
- create_table :images do |t|
- t.string :name
- t.references :image_collection, :polymorphic => true
- t.timestamps
- end
这个多态的reference，其实会生成两个字段:image_collection_id和:image_collection_type。
随之而来的那些方法
这是association带来的非常重要的东西，就是随着association的声明，会有一些相关的方法被创建出来。
比如我们声明了belongs_to关联之后，有四个方法被自动创建：
- association(force_reload = false)
- association=(associate)
- build_association(attributes = {})
- create_association(attributes = {})
又比如对于has_many关联，有如下方法被创建：
- collection(force_reload = false)
- collection<<(object, …)
- collection.delete(object, …)
- collection=objects
- collection_singular_ids
- collection_singular_ids=ids
- collection.clear
- collection.empty?
- collection.size
- collection.find(…)
- collection.exist?(…)
- collection.build(attributes = {}, …)
- collection.create(attributes = {})
正是这些方法，让代码变得简单。
举个简单的例子，还是上面那个customer、order模型：
- @customer.order_ids = [1, 2, 3]
这个方法会把customer原有的并且不在这个id list里的orders给清除掉，创建新的原来不存在的关联，同时，会自动save到数据库。曾经需要非常复杂的操作，现在变得如此简单。
还有，rails并不限制你为association添加自己的方法，这就是Association Extensions 。
何时保存到数据库
经过观察，发现对于大部分的关联，rails都会在赋值时自动把关联对象以及新的关联关系保存到数据库（除非你特别使用build方法来告诉rails不要save）。但对于belongs_to关联，却是个例外。比如对于上面account和company的例子：
- @account.company = @company
上面这条语句，并不会自动把@company（如果是一个new record）以及这两个对象之间的关联关系保存到数据库。
我觉得，这个例外的主要原因是：对于其它关联来讲，关联的key要么在一个中间表，要么在对方表上。比如：
- @company.account = @account
外键存在于accounts表上，而不是companies表上。
而对于belongs_to的关联，外键存在于自己表上。你给一个对象设置一些property，在没有调用save之前，它是不应该保存到数据库的。在如下这个场景里，就比较好理解为什么belongs_to关联不会自动保存到数据库：
- @account.name = "new account"
- @account.company = @company
- @account.value = 100.00
- # @account.save
在调用上面的save语句之前，@account肯定不应该保存任何数据到数据库。
而对于其它类型的关联，自动保存是比较合理的。比如：
- @company.account = @account
外键在accounts表上，这时候会自动把外键设上，并保存到数据库。而如果需要显示save才能保存，那么代码就会变得难看并且不合理：
- @company.account= @account
- # @account.save #需要显示保存account，而我们是在操作company
当然，上面讨论的前提是：自身对象本身已经被save了，而不是一个new record。
Association的弹性
Rails很精妙的一点在于，它用convention来使你省却很多麻烦，但它从来不限制你做什么，你如果觉得它的方式不好或者不适用，你可以去改变它。
对于association也一样，它提供了很多options。
比如对于company和account，外键默认是company_id，但你可以通过设定:foreign_key选项，来指定你希望的外键名称。
又比如，对于任何关联，rails都提供了默认的sql查询语句。但我们可以通过:finder_sql来改变它的查询语句。
Association，小心！
Association的使用和创建并不是随心所欲的，你还得小心以下几点：
1. 不要随心所欲地使用名字，至少，不应该跟model本身的instance method冲突。
2. 小心cache：所有的associaiton方法，都是在最近查询的cache上操作，如果你的程序的其它部分改变了数据，就需要reload这些数据。比如
- customer.orders # retrieves orders from the database
- customer.orders.size # uses the cached copy of orders
- customer.orders(true).empty? # discards the cached copy of orders
- # and goes back to the database
Association的罪恶
Association是魔法，但如果滥用，它是罪恶。
举一个例子。
有两个模型：
- class User
- has_many :lightboxes
- end
- class Lightbox
- belongs_to :user
- end
我们希望找出拥有lightbox，并且lightbox的images_count大于10的所有users。可能我们会使用下面这个查询语句：
- User.all(:include => [:lightboxes],
- :conditions => "lightboxes.id IS NOT NULL AND lightboxes.images_count > 10")
这个查询想当然地include（eager loading）了lightboxes，导致了两个罪恶：
1. 滥用include，:include应该在需要eager loading的时候使用，而不是把它用作:joins的替代（其实它不会替代，只是你以为而已）。在跟踪log的时候，你会看到这个查询导致了两个表之间的left join，这并不是include引起的，而是在你的conditions里面有其它表--lightbox--存在引起的（虽然它应该是通过association知道如何join这两个表）。
但使用left join和lightbox.id IS NOT NULL的方式去过滤没有lightbox的user是一种愚蠢的行为。正确并且快速的方式是使用inner join。
2. 很多人以为eager loading是用join来实现的，其实并不是(http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations )，至少Rails2.2之后不再是。那么，上面那个查询导致了一个很庞大但我们并不需要的数据库查询，即：
- SELECT * FROM lightboxes WHERE id IN (....................)
正确的查询语句应该是：
- User.all(:joins=> "INNER JOIN lightboxes ON users.id = lightboxes.user_id",
- :conditions => "lightboxes.images_count > 10")
当然，有人会说，这也不是“最美”的查询方式，你可以利用模型之间的association来写出一个更漂亮的查询，但上面这个查询是建立在“我们需要性能”的基础上的。
其它
关于association，还有其它一些重要的东西，比如 Association Callbacks ，就不再一一赘述了。本文完毕。
Reference:
莫愁前路无知己,天下无人不识君。
