ถ้า normalize มันจะลดความซ้ำซ้อนของข้อมูลลง เขียนโปรแกรมก็ง่ายขึ้นระดับหนึ่ง อัพเดตข้อมูลก็ทำที่ table เดียว ไม่ต้องไปแก้หลายที่

แต่ในทางปฏิบัติแล้ว เพื่อ performance บางทีเค้าก็ยอมให้มีความซ้ำซ้อนได้บ้าง เพราะถ้าแยก table กันหมด เวลา query ออกมาทีนึงมันต้อง join เยอะ ซึ่งการ join เนี่ยมันช้า

อย่างที่คุณ pittaya บอกส่วนหนึ่งก็คือลดความซ้ำซ้อนข้อมูล แถมด้วยลดพื้นที่เก็บไปได้เยอะ ซึ่งการ join ก็มีหลายแบบ ถ้าใช้ทั่ว ๆ ไปแล้ว join ไม่กี่ table ก็ไม่เท่าไหร่ แต่ถ้ามาก ๆ ก็ต้องใช้ join แบบอื่น ๆ ไปแทน แล้วบางครั้งไอ้ที่ normalize มามันมีข้อมูลที่จำกัด ก็มักจะใช้ ENUM แทนการสร้าง Table ใหม่ ก็ลดจำนวน Table ลงไปได้มาก อะไรแบบนี้

แล้วเรื่องการเปลี่ยนแปลงข้อมูลนีี่สำคัญมาก ถ้าข้อมูลเรามีต้องเปลี่ยนแปลงบ่อย ๆ การ normalize จะช่วยลดเวลาการเปลี่ยนแปลงลงไปได้เยอะ ยิ่งข้อมูลใน table ที่มีการ เปลี่ยนแปลงบ่อย ๆ มีการอ้างอิงถึงอยู่เสมอ ๆ ก็ช่วยลดเวลาและจำนวนข้อมูลในการเปลี่ยนแปลงข้อมูลไปที่ตารางอื่นได้มาก เพราะมันแค่อ้างอิง PM Key เท่านั้นส่วนข้อมูลภายในก็เหมือนเดิม แถมลดความคับคั้งของข้อมูลที่จะเปลี่ยนแปลงด้วย เพราะคุณส่งแค่ PM Key แทนข้อมูลจริง ๆ ไปเปลี่ยนแปลงข้อมูลเท่านั้น

ถ้างานในฐานข้อมูลแค่ใส่ข้อมูลและแสดงข้อมูลออกมา มีการลบและเปลี่ยนแปลงน้อย นี่ไม่ต้อง normalize มากมายก็ยังทำงานได้ดี แต่ถ้าเมื่อใดมีการลบและเปลี่ยนแปลง เยอะ ๆ นี่คงต้องดูความเหมาะสมเข้าว่าด้วย

ซึ่ง normalize มักทำพร้อม ๆ กับการทำ Transaction เพราะช่วยให้ข้อมูลนั้นปลอดภัยเพิ่มขึ้นด้วย (เท่าที่ผมจับมาก็มีอยู่ร่วมกันตลอดเลย) ------------------------------------ Ford AntiTrust’s Blog; Blog DeveloperOnTheRoad = new SoloGeek.ThaiCyberPoint(’Ford AntiTrust’s Blog’);

ผมว่าเวลาเขียนโปรแกรมอะไรซักอย่างที่มีการเก็บของข้อมูล การออกแบบฐานข้อมูลสำคัญที่สุดครับ... วันข้างหน้าจะได้ไม่ต้องมาปวดหัวที่หลัง....

------------------------------------- Little cow waiting the love โคน้อย คอยรัก...

หากมีการขยายขอบเขตของ database มันจะไม่ต้องมานั่งรื้อ ทำใหม่หมดไง

เหมือนข้อสอบวิชา database เลยแฮะ

การออกแบบ database ที่ดี table ควรจะนิ่ง คือ ถึงแม้จะมีการเปลี่ยนแปลงข้อมูลบ้าง (ไม่ใช่ใหม่หมด) ก็ไม่ควรจะต้องมีการ alter table เช่น เพิ่ม/ลบ column ควรจะทำแค่เพิ่ม/ลบ row เท่านั้นค่ะ ซึ่ง "ขยายออกไปทางขวา รวมทุกอย่างในตารางเดียว" มันขัดกับตรงนั้นสุดๆไง

เวลาอ.สอนออกแบบ table โดยค่อยๆทำตาม normalization form เริ่มจาก 1 แล้วแต่งไปเรื่อยๆ มันจะตลกๆ คือ แตกๆๆๆ มันออกไป สุดท้ายก็ต้องมายุบรวมกันอีกรอบ ตลกดี

เวลาผมออกแบบ DB ผมจะใช้หลักการแบบ Master Transaction แทน ระบบ normalization เพราะมันค่อนข้างเข้าใจ ยาก แต่ คำตอบ ที่ไ้ด้ จะเหมือน กัน ครับ

แต่บ้างครั้งถ้าต้องการ performance สูง ๆ ผม ก็ De- Normalization เหมือนกัน นะ

It's my life. Open your mind for the future.

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

แต่ผมมองดูอีกมุม จากการใช้ OO ในการทำงานนะครับ

การ normalize เกินไปทำให้การ พัฒนา program ลำบากขึ้นมาก

ในเรื่องของความสัมพันธ์นี่แหละครับ เพราะหาก split ตารางมากเกินไปแล้ว

การจัดการข้อมูลจะยิ่งยากขึ้นไปอีก ผมใช้วิธี ออกแบบเป็น object และความสัมพันธ์

ในเชิง object ทั้งหมด แล้วถือว่า ฐานข้อมูลมีหน้าที่เพียงเก็บข้อมูลเท่านั้น ครับ