Association — บทความ ผู้เขียน คอมเมนต์ ผูกกันยังไง

1 · ข้อมูลที่ผูกกัน — ใบคอมเมนต์มีช่อง "เป็นของบทความเลขที่ …"

แอปบล็อกเก็บของไว้ 3 ลิ้นชัก: ผู้ใช้ (users) · บทความ (posts) · คอมเมนต์ (comments) · คอมเมนต์ "น่ากินมาก" ต้องรู้ว่ามันอยู่ใต้บทความไหน และใครเป็นคนเขียน

วิธีที่ฐานข้อมูลใช้คือไม่ก๊อปบทความทั้งเรื่องมาไว้บนใบคอมเมนต์ แต่จดแค่เลขที่ของบทความ (id) ไว้ในช่องหนึ่งบนใบคอมเมนต์ · ช่องนั้นชื่อ post_id แปลว่า "เป็นของบทความเลขที่ …"

นี่คือหน้าตาจริงของสองลิ้นชักในแอปเรา (ตัดมาบางแถว บางช่อง):

ทำไมช่องนี้อยู่บนใบคอมเมนต์ ไม่ใช่บนบทความ? บทความหนึ่งชิ้นมีคอมเมนต์ได้ 0 อัน 2 อัน หรือ 100 อัน — เราเพิ่มช่องบนแฟ้มบทความให้พอทุกกรณีไม่ได้ · แต่คอมเมนต์หนึ่งอันอยู่ใต้บทความได้แค่ชิ้นเดียวเสมอ แค่ช่องเดียวก็พอ
ด้วยเหตุผลเดียวกัน บทความก็มีช่อง user_id = "เขียนโดยผู้ใช้เลขที่ …"

2 · กฎข้อเดียว: belongs_to อยู่ฝั่งที่มีคอลัมน์ _id

ช่อง _id อยู่ตารางไหน เปิดดูได้ในแปลนตู้ db/schema.rb (บท 108) · นี่คือของจริงจากแอปเรา ตัดมาเฉพาะส่วนที่เกี่ยว:

# db/schema.rb (ตัดมาบางส่วน)
  create_table "comments", force: :cascade do |t|
    t.text "body"
    t.bigint "post_id", null: false
    t.bigint "user_id", null: false
    …
  end

  create_table "posts", force: :cascade do |t|
    t.string "title"
    …
    t.bigint "user_id", null: false
    …
  end

  create_table "users", force: :cascade do |t|
    t.string "name"
    t.string "email"
    …
  end

  add_foreign_key "comments", "posts"
  add_foreign_key "comments", "users"
  add_foreign_key "posts", "users"

• t.bigint "post_id", null: false — ลิ้นชัก comments มีช่อง post_id เก็บจำนวนเต็ม (bigint = จำนวนเต็มขนาดใหญ่ ใช้เก็บเลขที่) · null: false = ห้ามเว้นว่าง
• ลิ้นชัก posts มีช่อง user_id · ลิ้นชัก users ไม่มีช่อง _id ของใครเลย
• add_foreign_key "comments", "posts" — กฎที่ตัวตู้: "เลขใน comments.post_id ต้องเป็น id ที่มีอยู่จริงในลิ้นชัก posts"
• … คือส่วนที่ผมตัดออก (ช่องอื่นที่ไม่เกี่ยว เช่น body · published · ช่องเวลาสร้าง/แก้ และสารบัญ t.index ที่ช่วยให้ค้นเร็ว — บท 109)
• force: :cascade — ข้ามได้ แปลว่า "ถ้ามีลิ้นชักชื่อนี้อยู่แล้วให้รื้อทิ้งสร้างใหม่" ใช้ตอนตั้งตู้ใหม่จากแปลน (บท 108) · ไม่เกี่ยวกับความสัมพันธ์ในบทนี้

ส่วน model ทั้งสามไฟล์ในแอปเราเขียนไว้แบบนี้ (ตั้งแต่บท 107):

# app/models/comment.rb
class Comment < ApplicationRecord
  belongs_to :post   # comments มี post_id
  belongs_to :user   # comments มี user_id
end

# app/models/post.rb
class Post < ApplicationRecord
  belongs_to :user   # posts มี user_id
  has_many :comments # post_id อยู่ฝั่ง comments
end

# app/models/user.rb
class User < ApplicationRecord
  has_many :posts    # user_id อยู่ฝั่ง posts
  has_many :comments # user_id อยู่ฝั่ง comments
end

สังเกตว่าทุกบรรทัดตอบได้ด้วยกฎเดียว: ตารางไหนมีช่อง xxx_id → model ของตารางนั้นเขียน belongs_to :xxx · ฝั่งที่ถูกชี้ถึงเขียน has_many (มีได้หลายอัน)
users ไม่มีช่อง _id เลย → User จึงไม่มี belongs_to สักบรรทัด

3 · ถามแฟ้มว่าเป็นของใคร — ลองใน console

พอเขียน belongs_to / has_many ไว้แล้ว Rails สร้าง method ให้ฟรี · เปิด bin/rails console แล้วพิมพ์ตามทีละบรรทัด (ผลจริง):

wongnok-blog(dev):001> comment = Comment.find(1)
  Comment Load (2.2ms)  SELECT "comments".* FROM "comments" WHERE "comments"."id" = 1 LIMIT 1 /*application='WongnokBlog'*/
=>
#<Comment:0x0000000123e82ca8
...
wongnok-blog(dev):002> comment.post_id
=> 1
wongnok-blog(dev):003> comment.post.title
  Post Load (1.3ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = 1 LIMIT 1 /*application='WongnokBlog'*/
=> "ต้มยำกุ้งน้ำข้น"
wongnok-blog(dev):004> comment.user.name
  User Load (1.1ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 2 LIMIT 1 /*application='WongnokBlog'*/
=> "สมหญิง"

• ... ใต้ => — console ย่อผลเพราะเป็นบรรทัดตั้งตัวแปร (บท 107) · พิมพ์ comment เฉย ๆ ถ้าอยากดูเต็ม
• comment.post_id → 1 — แค่ตัวเลขในช่อง ยังไม่ได้ไปไหน (ไม่มี SQL)
• comment.post — method ที่ได้จาก belongs_to :post · Rails เอาเลข 1 ไปหาในลิ้นชัก posts ให้ · SQL SELECT "posts".* FROM "posts" WHERE "posts"."id" = 1 LIMIT 1 แปลว่า "ขอทุกช่องจากลิ้นชัก posts เฉพาะแผ่นที่ id เป็น 1 เอาแผ่นเดียวพอ"
• comment.user.name — แบบเดียวกัน แต่ใช้เลขในช่อง user_id (= 2 คือสมหญิง)

ทีนี้ถามกลับทาง — จากบทความ ไปหาคอมเมนต์ทั้งหมด:

wongnok-blog(dev):005> post = Post.find(1)
  Post Load (1.0ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = 1 LIMIT 1 /*application='WongnokBlog'*/
=>
#<Post:0x0000000124c2e618
...
wongnok-blog(dev):006> post.comments
  Comment Load (1.0ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = 1 /* loading for pp */ LIMIT 11 /*application='WongnokBlog'*/
=>
[#<Comment:0x0000000124c2c958
  id: 1,
  body: "น่ากินมาก",
  post_id: 1,
  user_id: 2,
  created_at: "2026-11-04 12:02:56.246385000 +0000",
  updated_at: "2026-11-04 12:02:56.246385000 +0000">,
 #<Comment:0x0000000124c2c818
  id: 2,
  body: "ขอสูตรน้ำพริกเผาด้วย",
  post_id: 1,
  user_id: 3,
  created_at: "2026-11-04 12:02:56.250122000 +0000",
  updated_at: "2026-11-04 12:02:56.250122000 +0000">]

• post.comments — method ที่ได้จาก has_many :comments · SQL WHERE "comments"."post_id" = 1 แปลว่า "ไปลิ้นชัก comments หยิบทุกแผ่นที่ช่อง post_id เขียนว่า 1" — ตรงกับภาพนิติไล่หากล่องที่เขียนเลขห้อง
• /* loading for pp */ LIMIT 11 — console เติมเองเพื่อโชว์บนจอ (เหมือนบท 107) ไม่ใช่คำสั่งของคุณ
• post.comments เป็น relation (ใบเบิกของ — บท 113) จึงต่อ .where · .order · .count ได้อีก

เทียบกับ Go (GORM): บท 27 เราเขียน struct ให้ GORM ทีละช่อง · ถ้าจะผูกบทความกับคอมเมนต์ GORM ใช้ field สองแบบ (ผม compile และรันกับ Postgres จริงแล้ว):

type Post struct {
    ID       uint
    Title    string
    Comments []Comment // has many: ไม่มีคอลัมน์เพิ่มในตาราง posts
}

type Comment struct {
    ID     uint
    Body   string
    PostID uint // คอลัมน์ post_id อยู่ฝั่งนี้
    Post   Post // belongs to
}

// อยากได้คอมเมนต์มาด้วย ต้องสั่ง Preload เอง
db.Preload("Comments").First(&post, 1)

กฎเดียวกันเป๊ะ: PostID อยู่ใน Comment · ต่างกันที่ GORM ไม่ไปหยิบให้ถ้าไม่สั่ง Preload (ผมลอง db.First(&post, 1) เฉย ๆ ได้ len(post.Comments) เป็น 0) · Rails ไปหยิบให้เองตอนที่คุณใช้ post.comments ไม่ต้องสั่งล่วงหน้า — สะดวก แต่ก็เผลอไปตู้บ่อยเกินได้ (นั่นคือ N+1 ใน บท 114)

4 · ความสัมพันธ์ 5 แบบ — ใช้กฎเดียวกันทั้งหมด

Rails มีคำสั่งผูกความสัมพันธ์ 5 แบบ · ทุกแบบตอบด้วยคำถามเดียว "ช่อง _id อยู่ตารางไหน" (แถว has_one กับ habtm ไม่มีในแอปเรา เป็นตัวอย่างให้เห็นภาพเฉย ๆ):

คู่ที่คนสับสนบ่อยคือ belongs_to กับ has_one เพราะภาษาอังกฤษฟังคล้ายกัน ("โปรไฟล์เป็นของผู้ใช้" กับ "ผู้ใช้มีโปรไฟล์") · ไม่ต้องเดาจากความหมาย ใช้กฎ: ช่อง user_id อยู่ที่ profiles → Profile belongs_to :user · User เป็นฝั่ง has_one

5 · ของฟรีจาก has_many — สร้างคอมเมนต์โดยไม่ต้องเขียนเลขที่เอง

has_many :comments บรรทัดเดียวให้ method มาเป็นสิบตัว · ตัวที่ใช้บ่อยที่สุดคือสร้างคอมเมนต์ผ่านบทความ ซึ่ง Rails เติม post_id ให้เอง · เปิด console ใหม่แล้วลอง (ผลจริง):

wongnok-blog(dev):001> post = Post.find(1)
  Post Load (1.3ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = 1 LIMIT 1 /*application='WongnokBlog'*/
=>
#<Post:0x00000001239e87b0
...
wongnok-blog(dev):002> mana = User.find_by(name: "มานะ")
  User Load (1.7ms)  SELECT "users".* FROM "users" WHERE "users"."name" = 'มานะ' LIMIT 1 /*application='WongnokBlog'*/
=>
#<User:0x0000000123e6cbb0
...
wongnok-blog(dev):003> c = post.comments.create(user: mana, body: "ใส่มะนาวเยอะ ๆ")
  TRANSACTION (1.9ms)  BEGIN /*application='WongnokBlog'*/
  Comment Create (4.4ms)  INSERT INTO "comments" ("body", "post_id", "user_id", "created_at", "updated_at") VALUES ('ใส่มะนาวเยอะ ๆ', 1, 3, '2026-11-04 12:39:13.586700', '2026-11-04 12:39:13.586700') RETURNING "id" /*application='WongnokBlog'*/
  TRANSACTION (1.4ms)  COMMIT /*application='WongnokBlog'*/
=>
#<Comment:0x00000001240458b0
...
wongnok-blog(dev):004> c.post_id
=> 1

• post.comments.create(user: mana, body: "…") — "สร้างคอมเมนต์ใต้บทความนี้ เขียนโดยมานะ แล้วเก็บลงตู้เลย" · เราไม่ได้พิมพ์ post_id สักตัว
• user: mana — ส่ง object ผู้ใช้ไปทั้งตัว Rails หยิบเลขที่ (id = 3) ไปใส่ช่อง user_id ให้
• INSERT INTO "comments" ("body", "post_id", "user_id", …) VALUES ('ใส่มะนาวเยอะ ๆ', 1, 3, …) แปลว่า "เก็บแฟ้มใหม่ลงลิ้นชัก comments: ช่อง body = ใส่มะนาวเยอะ ๆ · post_id = 1 · user_id = 3" — เลข 1 มาจาก post ที่เราถือไว้
• BEGIN / COMMIT — เปิดและปิดรอบการเก็บ (transaction — บท 111) ข้ามไปได้

# สไลด์หน้า 41 เขียนไว้แบบนี้ — ลองพิมพ์ต่อใน console เดิม
hi = Post.find(3).comments.create(body: "hi")
hi.persisted?
hi.errors.full_messages

wongnok-blog(dev):005> hi = Post.find(3).comments.create(body: "hi")
  Post Load (2.5ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = 3 LIMIT 1 /*application='WongnokBlog'*/
=>
#<Comment:0x0000000124152fa0
...
wongnok-blog(dev):006> hi.persisted?
=> false
wongnok-blog(dev):007> hi.errors.full_messages
=> ["User must exist"]

ท่ายาว — เขียนเลขที่เอง

ถ้าไม่ใช้ has_many ก็สร้างคอมเมนต์ตรง ๆ ได้ แต่ต้องกรอกเลขเองทุกช่อง · เทียบสองแบบ:

# ท่ายาว: กรอกเลขที่เอง
Comment.create(post_id: post.id,
               user_id: mana.id,
               body: "…")

# ท่าสั้น: ฝากผ่านบทความ
post.comments.create(user: mana,
                     body: "…")

ได้ INSERT หน้าตาเดียวกัน · แต่ท่ายาวมีที่ให้พลาดเพิ่มหนึ่งที่: ถ้าพิมพ์ post_id: 2 ทั้งที่ตั้งใจจะใส่ 1 ก็เก็บได้สบาย ๆ เพราะบทความเลข 2 มีจริง ไม่มีใครฟ้อง คอมเมนต์ไปโผล่ผิดบทความ · ท่าสั้นพลาดแบบนี้ไม่ได้เลย เพราะเลขมาจากบทความที่ถืออยู่ในมือ
เทียบกับ Go: ใน GORM ของบท 27 เราก็ต้องเขียน Comment{PostID: post.ID, …} เอง — คือท่ายาวนี่แหละ

อีกเรื่องที่เห็นได้จาก log ของท่ายาว (ผลจริง · ผมเปิด console อีกหน้าต่างที่ใช้บทความเลข 2) · ท่อนนี้ดูอย่างเดียวพอ ไม่ต้องพิมพ์ตาม จะได้ไม่หลุดจาก console ของหัวข้อนี้:

wongnok-blog(dev):001> post = Post.find(2)
  Post Load (1.2ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = 2 LIMIT 1 /*application='WongnokBlog'*/
=>
#<Post:0x0000000124c78d80
...
wongnok-blog(dev):002> long = Comment.create(post_id: post.id, user_id: 1, body: "ท่ายาว")
  TRANSACTION (2.0ms)  BEGIN /*application='WongnokBlog'*/
  Post Load (3.8ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = 2 LIMIT 1 /*application='WongnokBlog'*/
  User Load (1.3ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1 /*application='WongnokBlog'*/
  Comment Create (2.6ms)  INSERT INTO "comments" ("body", "post_id", "user_id", "created_at", "updated_at") VALUES ('ท่ายาว', 2, 1, '2026-11-04 12:40:07.969344', '2026-11-04 12:40:07.969344') RETURNING "id" /*application='WongnokBlog'*/
  TRANSACTION (1.8ms)  COMMIT /*application='WongnokBlog'*/
…

ก่อน INSERT มี SELECT สองครั้ง — Rails เดินไปเช็คว่า "บทความเลข 2 มีจริงไหม · ผู้ใช้เลข 1 มีจริงไหม" ตามกฎของ belongs_to · ท่าสั้นไม่ต้องเช็ค เพราะเราส่งแฟ้มตัวจริงให้แล้ว
และถ้าไม่บอกบทความเลย ก็โดนปฏิเสธแบบเดียวกับ "hi" ข้างบน (ผลจริง หน้าต่างเดียวกัน):

wongnok-blog(dev):003> bad = Comment.create(user_id: 1, body: "ไม่มีบทความ")
…
wongnok-blog(dev):004> bad.errors.full_messages
=> ["Post must exist"]

build · count กับ size · comment_ids · <<

กลับมาที่ console ของหัวข้อนี้ (ที่ยังมี post = บทความ 1 กับ mana อยู่ · เลขบรรทัดข้างล่างนับต่อจาก predict "hi" ถ้าข้าม predict ไป เลขของคุณจะน้อยกว่า 3 ไม่เป็นไร) · ถ้าปิดไปแล้ว พิมพ์แค่บรรทัด 001–002 ใหม่ อย่าพิมพ์ create ซ้ำ ไม่งั้นตัวเลขจะไม่ตรงกับข้างล่าง · ลองสร้างแบบ "ถือไว้ในมือก่อน" ด้วย build แล้วนับดู (ผลจริง):

wongnok-blog(dev):008> draft = post.comments.build(user: mana, body: "ยังไม่ได้เก็บ")
=>
#<Comment:0x0000000124151ce0
...
wongnok-blog(dev):009> draft.post_id
=> 1
wongnok-blog(dev):010> draft.new_record?
=> true
wongnok-blog(dev):011> post.comments.count
  Comment Count (2.9ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 1 /*application='WongnokBlog'*/
=> 3
wongnok-blog(dev):012> post.comments.size
  Comment Count (2.6ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 1 /*application='WongnokBlog'*/
=> 4
wongnok-blog(dev):013> draft.save
  TRANSACTION (1.3ms)  BEGIN /*application='WongnokBlog'*/
  Comment Create (2.7ms)  INSERT INTO "comments" ("body", "post_id", "user_id", "created_at", "updated_at") VALUES ('ยังไม่ได้เก็บ', 1, 3, '2026-11-04 12:39:29.596118', '2026-11-04 12:39:29.596118') RETURNING "id" /*application='WongnokBlog'*/
  TRANSACTION (1.4ms)  COMMIT /*application='WongnokBlog'*/
=> true
wongnok-blog(dev):014> post.comments.count
  Comment Count (1.5ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 1 /*application='WongnokBlog'*/
=> 4

• build — เหมือน new ของบท 107 (สร้างไว้ในมือ ยังไม่ลงตู้) แต่เติม post_id ให้แล้ว · new_record? = true แปลว่ายังไม่ได้เก็บ
• count — ถามตู้เสมอ · SQL SELECT COUNT(*) … WHERE post_id = 1 = "นับว่ามีกี่แผ่นที่ post_id เป็น 1" → 3 (2 อันจาก seeds + อันที่เพิ่งสร้าง)
• size — ได้ 4 เพราะนับ "ในตู้ 3 + ที่ถือในมือยังไม่เก็บ 1" · พอ draft.save แล้ว count ก็เป็น 4 ตาม

อยากได้แค่เลขที่ของคอมเมนต์ทั้งหมดใต้บทความหนึ่ง ใช้ comment_ids (ผลจริง จากบทความเลข 5 ที่มี 3 คอมเมนต์ใน seeds):

wongnok-blog(dev):001> Post.find(5).comment_ids
  Post Load (1.7ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = 5 LIMIT 1 /*application='WongnokBlog'*/
  Comment Pluck (1.4ms)  SELECT "comments"."id" FROM "comments" WHERE "comments"."post_id" = 5 /*application='WongnokBlog'*/
=> [5, 6, 7]

ชื่อ method มาจากชื่อความสัมพันธ์: has_many :comments → ตัด s เติม _ids → comment_ids · SQL ขอแค่ช่อง id เหมือน pluck(:id) ของบท 113

สุดท้าย << (อ่านว่า "ต่อท้าย" — เครื่องหมายเดียวกับที่ใช้เติมของลง array ใน Ruby) ใช้กับคอมเมนต์ที่สร้างไว้ก่อนแล้ว (ผลจริง พิมพ์ต่อใน console เดิมที่มี post กับ mana):

wongnok-blog(dev):015> extra = Comment.new(user: mana, body: "ต่อท้ายด้วยลูกศร")
=>
#<Comment:0x0000000120b3e248
...
wongnok-blog(dev):016> post.comments << extra
  TRANSACTION (2.0ms)  BEGIN /*application='WongnokBlog'*/
  Comment Create (3.9ms)  INSERT INTO "comments" ("body", "post_id", "user_id", "created_at", "updated_at") VALUES ('ต่อท้ายด้วยลูกศร', 1, 3, '2026-11-04 12:39:34.387864', '2026-11-04 12:39:34.387864') RETURNING "id" /*application='WongnokBlog'*/
  TRANSACTION (2.0ms)  COMMIT /*application='WongnokBlog'*/
  Comment Load (1.5ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = 1 /* loading for pp */ LIMIT 11 /*application='WongnokBlog'*/
=>
[#<Comment:0x0000000120b3cd08
…(console โชว์คอมเมนต์ทั้ง 5 อันของบทความนี้ ผมตัดออก)
wongnok-blog(dev):017> extra.persisted?
=> true

<< ใส่ post_id ให้แล้วเก็บลงตู้ทันที ไม่ต้อง save ต่อ — ต่างจาก build ที่ยังอยู่ในมือ · (บรรทัด Comment Load … loading for pp ท้ายสุดคือ console ไปหยิบรายการมาโชว์บนจอ เหมือนหัวข้อ 3) · สรุปเป็นตาราง:

wongnok-blog(dev):003> post.comments.clear
  Comment Update All (1.7ms)  UPDATE "comments" SET "post_id" = NULL WHERE "comments"."post_id" = 2 /*application='WongnokBlog'*/
(wongnok-blog):3:in '<main>': PG::NotNullViolation: ERROR:  null value in column "post_id" of relation "comments" violates not-null constraint (ActiveRecord::NotNullViolation)

6 · ตั้งชื่อทางลัด — "บทความที่เผยแพร่แล้วของคนนี้"

หน้าโปรไฟล์ของผู้เขียนมักโชว์เฉพาะบทความที่เผยแพร่แล้ว · เขียนได้ว่า mana.posts.where(published: true) แต่ถ้าต้องพิมพ์ทุกที่ก็ยาวและลืมง่าย · Rails ให้ตั้งชื่อความสัมพันธ์ใหม่ที่มีเงื่อนไขติดมาด้วยได้ · แก้ไฟล์ app/models/user.rb เพิ่มบรรทัดสุดท้าย:

# app/models/user.rb
class User < ApplicationRecord
  has_many :posts
  has_many :comments
  has_many :published_posts, -> { where(published: true) }, class_name: "Post"
end

• :published_posts — ชื่อใหม่ที่เราตั้งเอง จะได้ method mana.published_posts
• -> { where(published: true) } — lambda = ก้อนโค้ดที่เก็บไว้รันทีหลัง (เจอครั้งแรกใน บท 112 · ญาติของ block บท 93) · แปลว่า "จดวิธีกรองไว้ก่อน ยังไม่ต้องทำ" แล้ว Rails เอามาต่อท้ายทุกครั้งที่เรียก published_posts
• ทำไมต้องห่อ? ถ้าเขียน where(…) เปล่า ๆ Ruby จะพยายามรันมันทันทีตอนอ่านไฟล์ ซึ่งตอนนั้นยังไม่รู้ว่าเป็นผู้ใช้คนไหน · ผมลองแล้ว Rails ไม่รับ ได้ NoMethodError
• class_name: "Post" — บอกว่าแฟ้มพวกนี้คือ Post · ต้องบอกเพราะ Rails เดา class จากชื่อ (บท 99): published_posts → PublishedPost ซึ่งไม่มี

ถ้าลืม class_name จะเจอแบบนี้ตอนเรียกใช้ (ผลจริง ตัดบรรทัดยาวท้าย ๆ ออก):

wongnok-blog(dev):002> mana.published_posts
(wongnok-blog):2:in '<main>': Missing model class PublishedPost for the User#published_posts association. You can specify a different model class with the :class_name option. (NameError)

ใส่ class_name แล้วปิด console เปิดใหม่ (console ไม่เห็นไฟล์ที่แก้ระหว่างเปิดค้าง — บท 104) · ผลจริง:

wongnok-blog(dev):001> mana = User.find_by(name: "มานะ")
  User Load (2.0ms)  SELECT "users".* FROM "users" WHERE "users"."name" = 'มานะ' LIMIT 1 /*application='WongnokBlog'*/
=>
#<User:0x0000000125c40ad8
...
wongnok-blog(dev):002> mana.posts.pluck(:title)
  Post Pluck (1.4ms)  SELECT "posts"."title" FROM "posts" WHERE "posts"."user_id" = 3 /*application='WongnokBlog'*/
=> ["ผัดกะเพราหมูสับ", "แกงเขียวหวานไก่"]
wongnok-blog(dev):003> mana.published_posts.pluck(:title)
  Post Pluck (1.0ms)  SELECT "posts"."title" FROM "posts" WHERE "posts"."user_id" = 3 AND "posts"."published" = TRUE /*application='WongnokBlog'*/
=> ["ผัดกะเพราหมูสับ"]

SQL บรรทัดที่สองแปลว่า "ขอแค่ช่อง title จากลิ้นชัก posts เฉพาะแผ่นที่ user_id เป็น 3 และ published เป็นจริง" · เงื่อนไขของเราไปต่อท้ายให้เอง · ได้ 1 เรื่อง เพราะ "แกงเขียวหวานไก่" ยังเป็นฉบับร่าง

เทียบกับ Go: ฝั่ง Go ที่ไม่มีของแบบนี้ให้ เราจะเขียนฟังก์ชันเล็ก ๆ อย่าง PublishedPosts(db, userID) ที่ใส่ Where("published = ?", true) ไว้ข้างใน แล้วเรียกฟังก์ชันนั้นทุกที่ · Rails ให้เขียนแค่บรรทัดเดียวใน model แล้วได้ method มาเลย

7 · หลายต่อหลาย — ติดป้ายให้บทความด้วย has_many :through

อยากให้บทความติดป้ายได้ เช่น "อาหารเผ็ด" · "สตรีทฟู้ด" · บทความหนึ่งติดได้หลายป้าย และป้ายหนึ่งก็อยู่ได้หลายบทความ · ช่อง _id จะอยู่ไหน? ใส่ tag_id ที่ posts ไม่ได้ (มีหลายป้าย) · ใส่ post_id ที่ tags ก็ไม่ได้ (อยู่หลายบทความ)

ทางออกคือลิ้นชักที่สามอยู่ตรงกลาง ชื่อ taggings (การติดป้าย) · แฟ้มหนึ่งแผ่นในลิ้นชักนี้คือ "หนึ่งคู่": มีช่อง post_id และ tag_id · ติดสองป้ายให้บทความเดียว = สองแผ่น

ลงมือ: สร้างป้ายกับใบจับคู่

ในโฟลเดอร์โปรเจกต์ สั่ง generator สองครั้ง (ผลจริง · เลขเวลาหน้าชื่อไฟล์ของคุณจะต่าง):

$ bin/rails generate model Tag name:string
      invoke  active_record
      create    db/migrate/20261104120348_create_tags.rb
      create    app/models/tag.rb
      invoke    test_unit
      create      test/models/tag_test.rb
      create      test/fixtures/tags.yml
$ bin/rails generate model Tagging post:references tag:references
      invoke  active_record
      create    db/migrate/20261104120349_create_taggings.rb
      create    app/models/tagging.rb
      invoke    test_unit
      create      test/models/tagging_test.rb
      create      test/fixtures/taggings.yml

• ครั้งแรก: model Tag + ลิ้นชัก tags ที่มีช่อง name
• ครั้งที่สอง: model Tagging + ลิ้นชัก taggings · post:references = "ช่องที่ชี้ไปหาแฟ้มในลิ้นชัก posts" (แบบเดียวกับตอนสร้าง Comment ในบท 107)
• บรรทัด test_unit กับไฟล์ใน test/ — ไฟล์เปล่าสำหรับเขียน test (Day 4) · วันนี้ไม่ต้องแตะ

เปิดดูของที่ generator เขียนให้ — ใบสั่งช่างกับ model ของ Tagging:

# db/migrate/20261104120349_create_taggings.rb
class CreateTaggings < ActiveRecord::Migration[8.1]
  def change
    create_table :taggings do |t|
      t.references :post, null: false, foreign_key: true
      t.references :tag, null: false, foreign_key: true

      t.timestamps
    end
  end
end

# app/models/tagging.rb
class Tagging < ApplicationRecord
  belongs_to :post
  belongs_to :tag
end

ตรงกับกฎเป๊ะ: ลิ้นชัก taggings มีช่อง post_id กับ tag_id → Tagging มี belongs_to สองบรรทัด
t.references :post = "ทำช่อง post_id ให้" (Rails เติม _id เอง) · null: false = ห้ามว่าง · foreign_key: true คือกฎที่ตู้ "เลขต้องมีจริง" · t.timestamps = ช่องเวลาสร้าง/แก้ · สั่งช่างลงมือ:

$ bin/rails db:migrate
== 20261104120348 CreateTags: migrating =======================================
-- create_table(:tags)
   -> 0.0080s
== 20261104120348 CreateTags: migrated (0.0080s) ==============================

== 20261104120349 CreateTaggings: migrating ===================================
-- create_table(:taggings)
   -> 0.0097s
== 20261104120349 CreateTaggings: migrated (0.0097s) ==========================

แล้วบอก Post ว่า "ป้ายของฉันหาได้โดยเดินผ่านใบจับคู่" · แก้ app/models/post.rb เพิ่มสองบรรทัดล่าง:

# app/models/post.rb
class Post < ApplicationRecord
  belongs_to :user
  has_many :comments
  has_many :taggings
  has_many :tags, through: :taggings
end

• has_many :taggings — บทความมีใบจับคู่ได้หลายใบ (post_id อยู่ฝั่ง taggings · กฎเดิม)
• has_many :tags, through: :taggings — "ป้ายของฉัน = ป้ายที่ใบจับคู่ของฉันชี้ไป" · ต้องมีบรรทัด has_many :taggings ด้วย ไม่งั้น Rails ไม่รู้ว่าจะเดินผ่านอะไร

เปิด console สร้างป้ายสองอัน แล้วติดให้บทความ (ผลจริง):

wongnok-blog(dev):001> spicy = Tag.create!(name: "อาหารเผ็ด")
  TRANSACTION (0.9ms)  BEGIN /*application='WongnokBlog'*/
  Tag Create (2.8ms)  INSERT INTO "tags" ("name", "created_at", "updated_at") VALUES ('อาหารเผ็ด', '2026-11-04 12:04:02.461063', '2026-11-04 12:04:02.461063') RETURNING "id" /*application='WongnokBlog'*/
  TRANSACTION (2.1ms)  COMMIT /*application='WongnokBlog'*/
=>
#<Tag:0x000000012300b288
...
wongnok-blog(dev):002> street = Tag.create!(name: "สตรีทฟู้ด")
…
wongnok-blog(dev):003> post = Post.find(1)
…
wongnok-blog(dev):004> post.tags << spicy
  TRANSACTION (1.0ms)  BEGIN /*application='WongnokBlog'*/
  Tagging Create (2.2ms)  INSERT INTO "taggings" ("post_id", "tag_id", "created_at", "updated_at") VALUES (1, 1, '2026-11-04 12:04:02.496763', '2026-11-04 12:04:02.496763') RETURNING "id" /*application='WongnokBlog'*/
  TRANSACTION (1.3ms)  COMMIT /*application='WongnokBlog'*/
  Tag Load (1.7ms)  SELECT "tags".* FROM "tags" INNER JOIN "taggings" ON "tags"."id" = "taggings"."tag_id" WHERE "taggings"."post_id" = 1 /* loading for pp */ LIMIT 11 /*application='WongnokBlog'*/
=>
[#<Tag:0x0000000122bcaa20
  id: 1,
  name: "อาหารเผ็ด",
  created_at: "2026-11-04 12:04:02.461063000 +0000",
  updated_at: "2026-11-04 12:04:02.461063000 +0000">]
wongnok-blog(dev):005> post.tags << street
…
wongnok-blog(dev):006> post.tags.pluck(:name)
  Tag Pluck (1.0ms)  SELECT "tags"."name" FROM "tags" INNER JOIN "taggings" ON "tags"."id" = "taggings"."tag_id" WHERE "taggings"."post_id" = 1 /*application='WongnokBlog'*/
=> ["อาหารเผ็ด", "สตรีทฟู้ด"]
wongnok-blog(dev):007> Post.find(2).tags << spicy
…
wongnok-blog(dev):008> Tagging.pluck(:post_id, :tag_id)
  Tagging Pluck (2.6ms)  SELECT "taggings"."post_id", "taggings"."tag_id" FROM "taggings" /*application='WongnokBlog'*/
=> [[1, 1], [1, 2], [2, 1]]

• post.tags << spicy — เราพูดถึงแค่บทความกับป้าย แต่ Rails สร้างใบจับคู่ให้เอง: INSERT INTO "taggings" ("post_id", "tag_id", …) VALUES (1, 1, …)
• Tagging.pluck(:post_id, :tag_id) → [[1, 1], [1, 2], [2, 1]] — ขอสองช่องเลยได้เป็นคู่ [เลขบทความ, เลขป้าย] · ใบจับคู่ 3 ใบ ตรงกับแผนภาพข้างบน
• … คือบรรทัดที่ผมตัดออก หน้าตาเหมือนบรรทัดก่อนหน้า

อ่าน JOIN เป็นภาษาคน: SELECT "tags"."name" FROM "tags" INNER JOIN "taggings" ON "tags"."id" = "taggings"."tag_id" WHERE "taggings"."post_id" = 1
= "เอาลิ้นชัก tags กับลิ้นชัก taggings มาวางคู่กัน · จับคู่แผ่นที่เลขป้ายตรงกัน (tags.id = taggings.tag_id) · เก็บเฉพาะคู่ที่ใบจับคู่เขียนว่าบทความ 1 · แล้วขอแค่ชื่อป้าย"
JOIN = ต่อสองลิ้นชักเข้าด้วยกันชั่วคราวตามเลขที่ตรงกัน · INNER = เอาเฉพาะแผ่นที่จับคู่ได้

เทียบกับ Go: GORM ก็มีแบบหลายต่อหลาย โดยเขียน tag บน field เช่น Tags []Tag `gorm:"many2many:post_tags;"` แล้ว GORM ทำตารางกลางให้ · ใกล้กับ habtm ข้างล่างมากกว่า เพราะไม่มี struct ของตารางกลางให้เราเห็น (ตัวอย่างจากเอกสาร GORM ไม่ได้รันในบทนี้)

through หรือ habtm — เลือกยังไง

แบบที่ 5 ในตารางหัวข้อ 4 (has_and_belongs_to_many) ก็ทำหลายต่อหลายได้ โดยไม่ต้องมี model ตรงกลาง · ผมลองในแอปทดลองแล้ว (ลองเสร็จลบทิ้ง): เขียน has_and_belongs_to_many :tags ใน Post แล้ว Rails ไปหาตารางกลางชื่อ posts_tags ให้เอง ซึ่งเราต้องสร้างให้มีแค่ post_id กับ tag_id — คู่มือทางการบอกให้สร้างแบบไม่มี id และไม่มี model

สไลด์หน้า 40 สรุปไว้ดี: ถ้าตารางกลางมีโอกาสได้ช่องเพิ่มในอนาคต ให้ใช้ :through ตั้งแต่แรก · คู่มือทางการของ Rails ก็บอกว่า :through ยืดหยุ่นกว่า ใส่ validation และช่องเพิ่มได้ (ลิงก์ท้ายบท) · วันนี้รู้จัก habtm ไว้แค่อ่านโค้ดคนอื่นออกก็พอ

ภารกิจ — ให้ป้ายรู้ว่าตัวเองอยู่บนบทความไหน (แบบฝึก Quiz 5 ของสไลด์)

wongnok-blog(dev):009> spicy.posts
(wongnok-blog):9:in '<main>': undefined method 'posts' for an instance of Tag (NoMethodError)

wongnok-blog(dev):002> Comment.column_names
=> ["id", "body", "post_id", "user_id", "created_at", "updated_at"]
wongnok-blog(dev):003> Tagging.column_names
=> ["id", "post_id", "tag_id", "created_at", "updated_at"]
wongnok-blog(dev):004> User.column_names
=> ["id", "name", "email", "created_at", "updated_at"]

# app/models/tag.rb
class Tag < ApplicationRecord
  has_many :taggings
  has_many :posts, through: :taggings
end

wongnok-blog(dev):001> spicy = Tag.find_by(name: "อาหารเผ็ด")
  Tag Load (2.0ms)  SELECT "tags".* FROM "tags" WHERE "tags"."name" = 'อาหารเผ็ด' LIMIT 1 /*application='WongnokBlog'*/
=>
#<Tag:0x000000012716a6e8
...
wongnok-blog(dev):002> spicy.posts.pluck(:title)
  Post Pluck (3.1ms)  SELECT "posts"."title" FROM "posts" INNER JOIN "taggings" ON "posts"."id" = "taggings"."post_id" WHERE "taggings"."tag_id" = 1 /*application='WongnokBlog'*/
=> ["ต้มยำกุ้งน้ำข้น", "ส้มตำปูปลาร้า"]

class User < ApplicationRecord
  has_many :posts
  has_many :comments
end

class Post < ApplicationRecord
  belongs_to :user                 # posts มี user_id
  has_many :comments               # สไลด์มี dependent: :____ ต่อท้าย — เฉลยบท 116
  has_many :taggings
  has_many :tags, through: :taggings
end

ทดสอบความเข้าใจ

ถ้าเปิดสไลด์ดูประกอบ

อ้างอิง

• Rails Guides — Active Record Associations · belongs_to — อ่านหัวข้อ belongs_to ถึง has_many และตัวอย่าง "Author must exist" ที่ตรงกับ "Post must exist" ของเรา
• Rails Guides — Methods Added by has_many — รายการ method ที่ได้ฟรีทั้งหมด (build · create · << · collection_singular_ids · clear)
• Rails Guides — has_many :through vs has_and_belongs_to_many — ส่วนที่บอกว่าเมื่อไหร่ควรเลือกแบบไหน · และหัวข้อ class_name · scopes
• Rails API — ActiveRecord::Associations::ClassMethods — เอกสารละเอียดของ has_many · belongs_to ทุก option · เปิดดูตอนอยากรู้ว่า option ไหนทำอะไร
• GORM — Belongs To · GORM — Has Many · GORM — Many To Many — ฝั่ง Go ที่เทียบในหัวข้อ 3 และ 7 · ดูว่า field PostID + Post และ tag many2many ทำงานยังไง
• PostgreSQL 17 — Foreign Keys — ฝั่งฐานข้อมูลของกฎ "เลขที่ต้องมีอยู่จริง" (add_foreign_key) · อ่านแค่ย่อหน้าแรกก็พอ