[DB] การออกแบบฐานข้อมูลที่ 1 Table Column เยอะๆ กับ หลาย Table แต่ต้อง Join อันไหนดีกว่ากัน

จริงๆ เรื่องนี้มันเป็นคำถามที่โลกแตกมากๆครับ ตอนที่เรียน Database Design มาการทำ Normalize จนถึง 3์NF หรือแบบสูดๆหน่อยก็ 6NF แล้วพอมาทำงานจริงเจอ 1 Table รวมมิตรสารพัดอย่าง แต่จริงๆแล้วเราควร Design เป็นแบบไหนหละ ?

จริงๆ เรื่องการออกแบบ Database มันส่งผลกับสถาปัตยกรรมของระบบนะ

รู้จักกับข้อมูลที่ต้องการจัดเก็บก่อน ?

• ลักษณะการใช้งาน มันมีพฤติกรรมแบบไหนนะ ?
• ต้องการให้ข้อมูลมันตรงหลังตาม ACID หรือป่าว ?

Solution ที่เป็นไปได้จากคำถามก่อนหน้า !!!!

• เน้นสำหรับออกรายงาน หรือ Warehouse
  • พฤติกรรมของ TABLE เป็น READ เยอะ / INSERT เยอะ และควรจะ DELETE น้อยครั้ง
  • ออกแบบตารางในลักษณะของการทำ Warehouse ได้ครับ (จริงๆ คือ Unnormalized ครับ ลดกาาร Join)
  • ถ้าทำแบบนี้ได้ Performance ในส่วนของ Index จะดีครับ
• เน้นสำหรับจัดการ Transaction ที่มีการเปลี่ยนบ่อย
  • พฤติกรรมของ TABLE เป็น INSERT, READ และ UPDATE เยอะครับ
  • อันนี้แนะนำให้ออกแบบตารางให้อย่ในรูป 3NF ก็พอครับ ส่วนพวกที่ต้อง Join เพิ่ม หรือ ข้อมูลที่ต้องดึงมาใช้งานด้วย อาจจะใช้วิธีของการทำ Cache ช่วยครับ
• ที่สำคัญต้องแยก
  • Database Table ที่ทำ Transaction  กับที่เป็น Warehouse  ออกจากกัน
    • เพื่อป้องกันปัญหา เรื่อง Concurrent Access และ Deadlock ได้
    • เป็นไปได้ควรแยกให้อยู่ DataFile คนละอัน และ Disk คนละก้อนครับ พอแยกกันคนละอัน การ Access สามารถทำแยกจากกันได้อย่างอิสระมากขึ้นครับ
    • แยกหลาย Table แล้ว อย่าลืมทำเอกสารสรุปนะ เพราะ เรายอมให้ Data มัน Duplicate ได้ หรือกำหนด Pattern ของชื่อ Field ให้สอดคล้องกัน เวลาปรับแก้อะไรจะได้ตามเก็บได้ครบด้วยครับ ^__^
  • มองให้ออกว่าเราสนใจการจัดการข้อมูล หรือสนใจเรื่องการนำเสนอข้อมูลครับ เพราะ ถ้าแยกไม่ออกแล้ว ไปๆมาๆ
    • งานที่อย่างกองไปที่ Database ฉันรับมันไว้เอง
    • Query ที่ได้ โคตรซับซ้อน และถ้าข้อมูล เราต้องทำ Index แต่ถ้า Index มันเยอะไปหละ พื้นที่ที่ใช้ก็เยอะ Insert + Update ช้าลงอีก

ข้อมูลเยอะ เราควรให้ Business Logic ไปไว้ที่ไหนหละ

• จริงๆแล้ว งานมันควรเน้นให้ Database ช่วยให้ได้มากที่สุดครับ ถ้า Software Product นั้นรองรับ Database แค่เจ้าเดียวเท่านั้นนะครับ
• แล้วงานระดับไหนที่เหมาะกับ DB หละ
  • งานที่คำนวณที่ไม่ซับซ้อนมาก และไม่ควรถึงต้องเขียน Store Procedure ที่ซับซ้อนมาก
  • จัดการข้อมูลที่ไม่ Dynamic ถ้าทำ Pivot หรือ พวก Cross Tab งานนี้ Dabase มันเก่ง แค่ SELECT * FROM TABLE หรือ VIEW ที่มันรู้จักครับ
• แต่ถ้า Software Product นั้น ต้องรองรับการใช้งาน Database ของหลายๆค่ายแล้ว
  

  ผมแนะนำให้ทำที่ Application ครับ เพราะ Maintain ได้ง่ายกว่า

  • ถ้าต้องเอางานมาทำที Appliation แล้ว Algorithm สำคัญมากครับ และอย่าลืม CPU กับ RAM เอามาใช้งานให้คุ้มนะครับ Design Software ให้รองรับพวก Thread ครับ ^___^
  • และที่สำคัญ ถ้า Logic แยกมาอยู่ที่ Application แล้ว มัน Design ให้สามารถ Test ได้ง่ายครับ

ปิดท้ายด้วย Normalized form จากแบบที่ไม่ระเบียบ มาจนมีระเบียบมากขึ้นครับ

• Denormalization
• UNF – Unnormalized form
• 1NF – First normal form
• 2NF – Second normal form
• 3NF – Third normal form
• EKNF – Elementary key normal form
• BCNF – Boyce–Codd normal form
• 4NF – Fourth normal form
• ETNF – Essential tuple normal form
• 5NF – Fifth normal form
• 6NF – Sixth normal form
• DKNF – Domain/key normal form