ActiveRecord Associations Basics
Fast recall
Quick revision
Core answer
Post has_many :comments and Comment belongs_to :post; the foreign key normally lives on the belonging table as comments.post_id. The Ruby declarations do not replace database design: migrations should add the reference, index, null rule, and foreign key needed for integrity, and destructive dependency behaviour such as dependent: :destroy must be chosen explicitly.Whether you know the common macros (belongs_to/has_many/has_one), what foreign key they rely on, and the convenience methods they give you.
Forgetting the foreign key convention (post_id) or confusing which side has belongs_to vs has_many.
belongs_to/has_many/has_one declare model links; they rely on foreign keys and give you post.comments and comment.post for free.
Interview-ready guide
Interview answer
An Active Record association describes how two model classes are related and gives Ruby methods for using that relationship. The relationship still rests on database columns. In a one-to-many example, one Post has many comments, and every Comment stores the post it belongs to.
Declare has_many :comments on Post and belongs_to :post on Comment. The foreign key belongs on the comments table as post_id, because each comment points to one post. The model declarations tell Rails how to navigate; they do not create the column themselves.
Rails then provides post.comments, comment.post, and collection builders such as post.comments.build(body: "Clear"). Building through the collection fills the relationship in memory; saving still runs the child's validations and write lifecycle. The association collection can also be filtered or ordered before it loads.
A migration should add the reference, index, null rule, and foreign-key constraint required by the domain. Choose dependent: :destroy only when child records truly belong to the parent's lifecycle, because it destroys them and runs callbacks. Audit records may instead need deletion restricted or their ownership preserved.
ActiveRecord Associations Basics
Direct Answer
Active Record associations declare relationships between model classes and provide methods for navigating and changing related records. In a one-to-many relationship, Post has_many :comments and Comment belongs_to :post; the foreign key normally lives on the belonging table as comments.post_id. The Ruby declarations do not replace database design: migrations should add the reference, index, null rule, and foreign key needed for integrity, and destructive dependency behaviour such as dependent: :destroy must be chosen explicitly.
Deep Dive & Architecture
An association method starts from key metadata. comment.post uses the comment's post_id to find the matching post primary key. post.comments builds the inverse condition. The returned collection is an association relation, so it can often be filtered or ordered before loading.
Building through an association sets linkage in memory. post.comments.build assigns the post relationship to the new comment; persistence still runs the comment's validation and write lifecycle. Creating the child does not automatically make a multi-record operation atomic, so transactions matter when several writes must succeed together.
Database foreign keys protect references even when SQL, background jobs, or another service writes outside the Rails model. An index on the foreign-key column supports the lookup direction. Model-level presence rules improve feedback but cannot replace those database guarantees.
Dependency options encode ownership. If comments have no meaning without their post, destroying them may be correct. If records must remain for audit, cascade deletion may be destructive. Model behaviour and database ON DELETE actions must be designed together so they do not contradict or unexpectedly duplicate work.
Code Example
class Post < ApplicationRecord
has_many :comments, dependent: :destroy
end
class Comment < ApplicationRecord
belongs_to :post
end
class AddPostToComments < ActiveRecord::Migration[8.1]
def change
add_reference :comments, :post,
null: false, index: true, foreign_key: true
end
end
post = Post.new
comment = post.comments.build(body: "Clear explanation")
puts comment.post.equal?(post)
Common Mistakes & Pitfalls
Forgetting the foreign key convention (post_id) or confusing which side has belongs_to vs has_many.
Check your understanding
Answer these without looking back at the article.
- Which table owns the foreign key in a `has_many` / `belongs_to` relationship?
- What is the difference between an association declaration and a database foreign key?
- How do `dependent: :destroy` and direct dependent deletion differ?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.