By: crucifier 
on 14 January 2007 - 09:20
Tags:
Forums:
พอทราบครับว่าการออกแบบตารางในฐานข้อมูล ไม่ควรขยายออกไปทางขวา ไม่ควรรวมทุกอย่างในตารางเดียว แต่ควรแยกออกมาในลักษณะเชื่อมโยงกันมากกว่า เพราะอะไรจึงต้องเป็นแบบนั้นครับ มันง่ายต่อการพัฒนาและเขียนโปรแกรมด้วยหรือเปล่า รู้แต่ว่าดี แต่พอมีคนถาม กลับตอบไม่ได้ -*-
ขอความกรุณาด้วยครับ
Get latest news from Blognone
Follow @twitterapi
ถ้า normalize มันจะลดความซ้ำซ้อนของข้อมูลลง เขียนโปรแกรมก็ง่ายขึ้นระดับหนึ่ง อัพเดตข้อมูลก็ทำที่ table เดียว ไม่ต้องไปแก้หลายที่
แต่ในทางปฏิบัติแล้ว เพื่อ performance บางทีเค้าก็ยอมให้มีความซ้ำซ้อนได้บ้าง เพราะถ้าแยก table กันหมด เวลา query ออกมาทีนึงมันต้อง join เยอะ ซึ่งการ join เนี่ยมันช้า
pittaya.com
อย่างที่คุณ 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.
ขอบคุณทุกคนมากครับ แม้จะใช้เป็น ทำเป็น แต่ผมค่อนข้างเป็นคนที่....ไร้ภูมิ (?) คือเค้าสอนยังไงก็ทำยังงั้น ถึงเวลาต้องวิเคราะห์ผลดีผลด้อยก็ไปไม่รอด เหมือนกรณีนี้แหละครับ
หัวหน้าผมเค้าพอมีความรู้เรื่อง database บ้าง สไตล์เค้าก็จะออกทางขวาหมดครับ แล้วก็มาถกกันว่าทำไมผมทำอีกไปอีกแนวทาง ที่จริงเค้าก็แค่อยากรู้ว่าผมมีเหตุผลที่ดีหรือเปล่า ปรากฎว่าคิดหาเหตุผลไม่ออกครับ -*-"
อาจารย์ผมเคยสอนไว้ว่าหัวใจของ Normalization คือ "อย่า split ตารางโดยไม่จำเป็น" ครับ และเค้าบอกว่าถ้าใครถามว่าจะ split ทำไมให้ตอบว่า เราจะแก้ปัญหาที hardware แก้ไม่ได้ก่อน ไม่รู้ว่าช่วยได้หรือเปล่า แต่ก็เป็นข้อมูลครับ ^^
แต่ผมมองดูอีกมุม จากการใช้ OO ในการทำงานนะครับ
การ normalize เกินไปทำให้การ พัฒนา program ลำบากขึ้นมาก
ในเรื่องของความสัมพันธ์นี่แหละครับ เพราะหาก split ตารางมากเกินไปแล้ว
การจัดการข้อมูลจะยิ่งยากขึ้นไปอีก ผมใช้วิธี ออกแบบเป็น object และความสัมพันธ์
ในเชิง object ทั้งหมด แล้วถือว่า ฐานข้อมูลมีหน้าที่เพียงเก็บข้อมูลเท่านั้น ครับ