Data Normalization นั้นดีจริงหรือ

แค่อ่านหัวข้อก็รู้แล้วนะครับว่าบทความนี้ตั้งใจจะแสดงอีกแง่มุมหนึ่งซึ่งแตกต่างระหว่าง "การทำ Data Normalization ในภาคทฤษฏีและภาคปฏิบัติที่ส่งตรงมาจากประสปการณ์การทำงาน" ซึ่งต้องออกตัวก่อนว่าบทความนี้เป็นแค่ความคิดเห็นส่วนตัวของผมซึ่งอาจจะผิดหรือถูกก็แล้วแต่วิจารณญาณและสถานการณ์การนำไปใช้ของแต่ละคน ก่อนอื่นใดมาทำความรู้จักกับการทำ Database Normalization เพื่อปูพื้นฐานกันก่อนเลยครับ

Database Normalization คืออะไร
ถ้าว่าด้วยศาสตร์ของ Relational Database Design แล้ว Database Normalization ถือเป็นบทพื้นฐานที่นักศึกษา Computer Science จะต้องทำความเข้าใจ (แต่เหมือนไม่เคยผ่านตายังไงไม่รู้แฮะ) ซึ่งถ้าจะให้คำนิยามของการทำ Data Normalization แล้วมันก็คือ

การทำให้รูปแบบโครงสร้างของฐานข้อมูล (Database) อยู่ในรูปของ
Normal Form (NF) ซึ่งจะสามารถลดความซ้ำซ้อนของข้อมูล,
ลดพื้นที่เก็บข้อมูลและขจัดปัญหาความผิดปกติของข้อมูล

ที่เกิดจาก 3 สาเหตุหลัก

1. Insertion Anormalies
2. Deletion Anormalies
3. Update Anormalies

หรือก็คือความผิดปกติจากการ เพิ่มข้อมูล ลบข้อมูล และ ปรับปรุงข้อมูลได้สามารถแบ่งออกได้เป็น 5 ระดับ ซึ่งในบทความนี้จะไม่ลงลึกถึงรายละเอียดไปมากกว่านี้เพราะเดี๋ยวจะกลายเป็นบทความสอนการทำ Normalization ไป เอาเป็นว่าถ้ายังไม่มีพื้นฐานก็สามารถไปศึกษาต่อได้ใน http://en.wikipedia.org/wiki/Database_normalization หรือ หนังสือ Database Design ทั่วไปนะครับ

คราวนี้เราก็ได้รู้ถึงความหมายและประโยชน์ของการทำ Normalization ไปแล้ว หลายท่านอาจจะคิดว่า ในเมื่อประโยชน์มันเห็นได้ชัดขนาดนี้ แถมตอนเรียนทั้งอาจารย์ทั้งตำราจากหลายสำนักก็เน้นนักเน้นหนาว่าการทำ Normalization นั้นมีความสำคัญยิ่ง แล้วทำไมถึงจะไม่ใช้ล่ะ จากตรงนี้ผมสรุปว่า "แล้วแต่กรณีครับ"

การทำ Normalization นั้นดีแน่อย่างที่อาจารย์ท่านสอนแหละครับ แต่!!~ (ลูบหลังแล้วตบหัว) ท่านรู้หรือไม่ว่าผลของการทำ Normalization จะทำให้เกิดตารางมากมายเพื่อจุดมุ่งหมายในการลดความซ้ำซ้อนของข้อมูล หรือถ้าถ้าให้พูดแบบตรงประเด็น

"การทำ Normalization
ในทัศนะของข้าพเจ้าคือการลดความซ้ำซ้อนของข้อมูลแต่เพิ่มความซับซ้อนของข้อมูลหากใช้ไม่เหมาะสมกับกรณี"

นั่นเองและสิ่งที่ตามมาที่ Software Developer หรือแม้แต่ Software Engineer ทั้งน้อยใหญ่มองข้ามในประเด็นแรกก็คือ Performance Issue ครับ

ผมคงจะไม่ปฏิเสธที่ตำราหรืออาจารย์บอกให้ทำ Normalization แต่นั่นเหมาะสมและดีที่สุดสำหรับระบบใหญ่มากหรือใช้ร่วมกับ OR-Mapping แต่สำหรับ Application ในปัจจุบันการเลือกใช้ Normalization นั้น Software Develoer ยังเลือกใช้ได้ไม่เหมาะสมเท่าที่ควร เนื่องจากการแตกกระจายตัวของตารางนั้นก่อให้เกิดความยุ่งยากมากมายในการพัฒนา Application ยกตัวอย่างเช่น ถ้าท่านจะเขียน Summary Report ขึ้นมา 1 ตัว โดยดึงข้อมูลจากตารางที่ทำ Normalization สิ่งที่หลีดเลี่ยงไม่ได้คือการ Join ตารางเพื่อให้ได้ข้อมูลที่ครบถ้วน ซึ่งแน่นอนการ Join Table นั้น "กิน CPU มากกว่า" Select Statement ธรรมดาอยู่แล้ว ซึ่งทำให้บางครั้งการ Select 1 ครั้งอาจกินเวลาร่วมชั่วโมงเลยก็มี ประเด็นนี้เป็นประเด็นที่สำคัญมาก แต่หลายคนยังมองข้ามอยู่

การสร้างระบบที่สามารถรองรับได้หลาย Concurrent Users นั้นจำเป็นต้องมี Performance ที่ดี (อาจจะต้องลงลึกไปถึงระดับ SQL Optimization) ยิ่งจำนวนผู้ใช้งานระบบเยอะ Database Server ยิ่งทำงานหนัก ดังนั้นหากไม่มี Performance Tuning ที่ดีแล้ว อาจจะตามมาด้วยความเสียหายในธุรกิจที่ประเมิณค่าไม่ได้ก็เป็นไปได้ จากประสปการณ์ตรง ผมเคยเจอแบบนี้ครับ (พร่ามมาตั้งนาน ในที่สุดก็ยอมสารภาพ T^T) ต้องทำการ Maintainance ตัว Compliance Date Report จากฐานข้อมูลที่ทำการ NF และมี Concurrent Users ทั้งบริษัทครับ ผลก็คือผมต้องไปไล่ตาม Table ที่กระจัดกระจายอยู่เต็มไปหมด เจอ Sub Query ที่ผลาญ CPU ไปจำนวนมหาศาล เคยคิดจะแก้โดยการเขียน Query Catche หรือการทำ Index เพื่อช่วยเรื่องความเร็ว ขึ้นมาแทนครับ แต่ก็ยังไม่เร็วขึ้นเท่าไหร่ และที่สำคัญ ถ้ามี User กด Print Report นั้นขึ้นมาระบบอึดขึ้นทันตาเห็นเลยครับ หลายท่านอาจจะมองว่าแล้วทำไมไม่ไปแก้ไขที่ Hardware ล่ะ นั่นเป็นวิธีที่ไม่ได้ประสิทธ์ภาพเท่าไหร่นัก

ทำไมล่ะ ก็เครื่องมันช้าก็ต้องซื้อโน่นซื้อนี่มาเพิ่มสิ?

นั่นก่อให้เกิดความสิ้นเปลืองโดยที่ยังใช้เครื่องมือที่มีได้ไม่เต็มประสิทธิภาพ ปัจจุบันราคา Database Server นั้นสูงนะครับซึ่งอาจจะทำให้การอนุมัติขอซื้อจากบางบริษัทนั้นไม่ใช่เรื่องง่าย ไหนจะเสี่ยงต่อการที่ Hardware ตัวใหม่ที่ซื้อมาจะสร้างปัญหาหรือต้องลงทุนในการจ้างคนดูแลมากขึ้นไปอีกแถมยังต้องเจอกับประเด็นที่สองที่ทุกคนมองข้ามนั่นคือ "ความยุ่งยากมากกว่า" ที่เกิดจากการเขียน SQL Statement จนทำให้เราคิดกันจนผมหงอก หลายท่านอาจะไม่มองข้อนี้เป็นปัญหา แต่ท่านอย่าลืมว่า ถ้า Software Developer ใช้เวลามากขึ้นในการพัฒนา Application นั่นหมายถึง Cost ที่เพิ่มขึ้นและ Timeline ที่อาจจะเกินเวลาซึ่งอาจจะทำให้ Project นั้นเกิดอาการที่เรียกว่า "Delay" ได้ครับ

ดังนั้นจาก Case Study (ของผม) จะเห็นได้ว่า Normalization ไม่ใช่สิ่งที่จำเป็นที่สุดในการ Design Database ครับ มันขึ้นอยู่กับว่า เรามีจุดมุ่งหมายอะไรมากกว่า ซึ่งการ Design ในปัจจุบันก็มีให้เลือกใช้ได้ตั้งหลายแบบครับ ทั้ง Normalization, Demormalization, Centralization หรือรูปแบบอื่น

เขียนซะยาวแต่นั่นก็คือประสปการณ์ที่ผมอยากจะมาแบ่งปันให้ทุกคนครับ จะได้ไม่ยึดติดกับการทำ Normalization มากเกินไปวันนี้ไปก่อนครับ