ความเข้าใจผิดที่เห็นบ่อย
"การเลือกใช้ RDBMS แล้วทีมพัฒนาจะคิดเรื่อง Schema ให้ดี วางแผนเรื่องข้อมูลเยอะๆ แล้วเราจะได้ Structure ของข้อมูลที่ดี"
ผมคิดว่าการใช้ RDBMS โดยคาดหวังผลลัพธ์ว่าจะได้บังคับทีมพัฒนาให้คิดเรื่อง Data structure ให้ดีก่อนทำอะไร ไม่เคยได้ผลจริงเลย
อันนี้มักจะเป็นความเข้าใจของคนที่ดูแลฐานข้อมูลหรือ Infrastructure แต่ไม่ได้ร่วมงานกับทีมพัฒนา ที่ว่าพอเสนอ Field Migration แล้วถูกตั้งคำถามจากฉัน เขาจะได้คิดดีๆ ก่อนเสนอ แล้วเราจะได้มี Data schema ที่งดงามไม่ Bloat โอ้ มันช่างดี มันต้องได้ผลแน่ๆ
ในความเป็นจริงผมเห็นมาหลายระบบแล้ว พอคุณทำให้ Field Migration มันยาก คนไม่ได้คิดให้ดีก่อนเสนอ Schema change ครับ คนเขาจะพยายาม Reuse field เก่ามาใช้หลายๆ อย่างแทนครับ เพราะเขามานั่งรอคุณตั้งคำถามไม่ได้ เขามีงานที่ต้อง Deliver
สิ่งที่เกิดขึ้นคือเราจะมีฟิลด์ที่มีหลายความหมาย ซึ่งไม่ใช่การออกแบบที่ Data ที่ดีเลยแม้แต่นิดเดียว
นั่นคือ Actual consequence ไม่ใช่การที่คนคิดให้ดี แต่เป็นการที่คนขี้เกียจทำไปเลย
แต่ถ้าคนที่เสนอสิ่งนี้ ไม่ได้อยู่ในทีมพัฒนา เช่น อยู่ในองค์กรที่มี DBA แยกกันกับทีมพัฒนาอย่างสมบูรณ์จนกระทั่งไม่รู้เลยว่าข้อมูลพวกนี้ไปใช้ในส่วนไหนของซอฟต์แวร์บ้าง จะไม่รู้ไง เห็นว่า Database schema/Structure เหมือนเดิม ก็เข้าใจผิดไปว่านี่คือออกแบบ Data มาดีแล้ว
"ดูสิ ออกแบบครั้งเดียวใช้ได้เป็นปีเลยนะ เห็นป่ะ อยากออกแบบดีๆ ให้ไม่ต้องเปลี่ยนก็ทำได้นี่" เขาจะเข้าใจประมาณนี้ เพราะไม่เห็นว่าเนื้อซอฟต์แวร์เอาฟิลด์ไปใช้อะไรบ้าง
จนกระทั่งต้องเริ่มทำ BI ถึงจะเห็นปัญหาว่าอ้าว ฟิลด์นี้มันหมายถึงหลายอย่างเลยนี่หว่า จะเอาไป Analyze ยังไงล่ะ
RDBMS มีประโยชน์หลายอย่างมากๆ ผมก็ชอบ RDBMS แต่ผมไม่เห็นด้วยกับเคลมที่ว่า พอใช้ RDBMS แล้วจะบีบให้ทีมคิดให้ดีก่อนทำ Database schema ไม่เคยเห็นเกิดขึ้นจริงมาก่อน
นี่คือเหตุผลหนึ่งที่คนทำงาน Infra ควรจะอยู่ในทีมพัฒนา ไม่ใช่แยกกันทำงาน ฉันดูแลระบบ แกพัฒนา พอมันแยกกัน ความเข้าใจผิดก็เกิดขึ้นได้ง่ายมาก