ก็คงคู่ขนาน ทำ manual ก่อน แล้วเอามาคีย์ผ่านระบบทีหลังนั่นแหล่ะครับ แย่สุด ก็คือ ต้องคีย์ทั้งระบบเดิม และระบบใหม่ด้วย หรือให้คนรับงานไปทำโปรแกรมให้คีย์ผ่าน excel แล้วดัมป์เข้าไป ก็ว่ากันไป ก็อย่างว่าแหล่ะครับ ระบบ run ไปแล้ว มีปัญหาก็ต้องแก้ไขปัญหากันไป จนกว่าระบบจะนิ่ง ซึ่งส่วนใหญ่ก็เป็นปีนั่นแหล่ะ แต่โดยปรกติถ้าเป็นบริษัททั่วไปเขาจะแนะนำทำคู่ขนานไปซัก 3 เดือนก่อน โดยระบุเจ้าหน้าที่ช่วยคีย์งานเอาไว้ใน TOR เลย เพื่อให้ช่วยงานในระหว่าง implement ระบบ แล้วค่อยๆ ลดการใช้งานระบบเก่านะ

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

แต่เท่าที่ผมเจอนะ ส่วนใหญ่จะเจอ JOIN ข้อมูลแบบซ้อนกันหลายชั้น เนื่องจากดันไปออกแบบ normalize จนอยู่ในระดับที่ย่อยสุด พอต้อง join กลับเพื่อนำไปใช้งานมันต้องเขียน SQL เพื่อ Join ตารางจำนวนมาก แล้วหากแจ็คพ็อตไปใช้ตารางที่มีการเขียนบ่อยๆ ก็อาเมนแหล่ะครับ วิธีแก้คงต้องให้ผู้รู้่ของบริษัทรับงานไปจัดการแหล่ะ เพราะมันต้องแก้ไขหลายอย่าง รวมถึงคนที่จะสั่งงานต้องเคยเป็นทั้ง DB Admin แล้วก็เคยเขียนโปรกรมด้วย เพราะอาการนี้บอกเลยว่าใช้ความรู้เฉพาะด้านใด ด้านหนึ่งไม่ได้มันเป็นปัญหาองค์รวม

ผมเคยเจอกับตัวเองมางานหนึ่ง ของอีกบริษัท ผมคุยกับเจ้าหน้าที่ เขาบอกมีการ join ตาราง เกือบ 30 ตาราง แล้วระบบมันช้า ทำไงดีพี่ ผมนี้ร้อง ฮ้า แล้วก็บอกว่า อย่างนี้แก้จบยากเลย มันเป็นมาตั้งแต่ชั้นออกแบบ แต่ก็ใช่ว่าจะไม่มี แต่ต้องแลกมาด้วยอาจต้องลดความ real-time กลายเป็นกึ่ง real-time แทน ซึ่งส่วนใหญ่จะไปเจอปัญหาอีกว่า ดันเขียนใน TOR ด้วยว่าต้อง real-time