ในโลก Data Warehouse หลายๆ คนอาจจะเคยได้ยินคำว่า Slowly Changing Dimension (SCD) กันมาบ้างเนอะ แล้วมันคืออะไรล่ะ? มันคือการจัดเก็บข้อมูลที่มีการเปลี่ยนแปลงไปเรื่อยๆ และที่เค้าบอกว่า slow เนี่ย เค้าหมายถึงข้อมูลที่เป็น dimension เนอะ เช่น ชื่อคน เพศ หรือ ชื่อ product อะไรแบบนี้ที่ไม่ได้มีการเปลี่ยนแปลงบ่อย ซึ่งโดยปกติแล้วข้อมูล dimension ก็จะเป็นประมาณนั้นอยู่แล้ว (แต่ถ้ามีการเปลี่ยนแปลงเร็วจริงๆ ลองดู Rapidly Changing Dimension เพิ่มนะ)
ลองนึกถึงการเก็บข้อมูลใน app สักตัวหนึ่ง อย่างเช่นข้อมูล order สินค้า แล้วก็มีฟิลด์ status เพื่อบอกว่าตอนนี้ order อยู่ในสถานะอะไร แล้วทีนี้ใน app ของเราเวลาที่มาอัพเดท status เราก็จะมาอัพเดทที่ข้อมูลเดิมกันเลยใช่ไหม? 
มาดูตัวอย่างกันให้ชัดๆ สมมุติว่าเรามีข้อมูลตั้งต้นประมาณนี้
| id | status | updated_at |
|---|---|---|
| 1 | pending | 2019-01-01 |
แล้วพอสถานะเปลี่ยน ข้อมูลก็จะกลายเป็นแบบนี้
| id | status | updated_at |
|---|---|---|
| 1 | shipped | 2019-01-02 |
ทีนี้มันก็มีปัญหาอยู่ว่าถ้าเราต้องการที่จะวิเคราะห์ช่วงระยะเวลาระหว่างจากสถานะ pending ไปเป็น shipped เนี่ย เราไม่สามารถที่จะรู้ได้เลย หรือถ้าเราต้องการที่จะดูว่าก่อนสถานะเป็น shipped เนี่ย มันเคยเป็นสถานะอะไรมาก่อน?
ตรงนี้แหละครับที่เราสามารถเอา SCD มาใช้ได้ โดยที่นิยมใช้ๆ กันก็คือ Type-2 อธิบายง่ายๆ มันก็คือการเพิ่มข้อมูลมาอีก 1 แถวโดยที่ยังเก็บข้อมูลเก่าไว้
จากตัวอย่างข้อมูลด้านบน เราก็จะสามารถเก็บข้อมูลได้เป็นแบบนี้
| id | status | updated_at | from | to |
|---|---|---|---|---|
| 1 | pending | 2019-01-01 | 2019-01-01 | 2019-01-02 |
| 1 | shipped | 2019-01-02 | 2019-01-02 | null |
ซึ่งเราก็อาจจะมีฟิดล์ from กับ to เอาไว้บอกสักหน่อยว่าค่าๆ นี้เริ่มตั้งแต่เมื่อไหร่ และถึงเมื่อไหร่ถึงจะเปลี่ยนไปเป็นค่าใหม่ ก็เป็นอันเรียบร้อย… เรื่อง Type-2 SCD ก็ประมาณนี้แหละ 
จริงๆ เรื่องนี้เราสามารถพูดคุยตกลงกับทางสายพัฒนา software ได้เลยนะ หาทางออกร่วมกันว่าแบบไหนจะดีที่สุดสำหรับพวกเรา ตั้งแต่ในระดับ app เราสามารถเก็บ history ไว้ได้หรือเปล่า? ถ้าไม่ได้ แล้วเราสามารถทำเป็น change event มาได้ไหม? แล้วถ้าไม่ได้ โอเคเราสามารถเอามาทำ Type-2 SCD ก็พอจะตอบโจทย์การวิเคราะห์ข้อมูลไหม? บลาๆ
ฮ่าๆ ถ้าถามผมเนี่ย ผมไม่มีคำตอบที่ดีที่สุดให้นะครับ อันนี้อยู่ที่บริบทการคุยกันภายในทีมของแต่ละองค์กรเลย ทุกทางเลือกมี technical debt หมด อยู่ที่เราจะจัดการมันอย่างไร 
Ref: Snapshots | dbt Docs
