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

ทางเลือกมีไม่มาก ผมเลยเริ่มหันมามอง NoSQL อย่างจริงจัง ซึ่งถึงมันเพิ่งจะเริ่มตั้งไข่ได้ไม่กี่ปี แต่ผมก็คิดว่าในอนาคตผมต้องได้ใช้มันแน่ ๆ

ปัญหาที่ตอนนี้ผมเจอเกี่ยวกับ NoSQL ก็คือแนวความคิดที่่ว่า มันจะไม่มีการ JOIN ระหว่างตารางข้อมูล มันขัดกับหลักพื้นฐานที่ร่ำเรียนมามาก ๆ และการประยุกต์ใช้ในทางปฏิบัติมันก็หลีกเลี่ยงการ JOIN ไม่ได้ด้วยอ่ะดิ เพราะข้อมูลในทางธุรกิจมันพัวพันยึดโยงกันอยู่ มันควรจะแยกอิสระออกจากกันแล้ว JOIN กันตามแบบเดิม ๆ ที่เคยเป็น

ถ้า DBMS แบบ NoSQL ไม่ยอมทำเรื่อง JOIN ข้อมูล งั้นก็คงมีทางเลือกสองทาง คือออกแบบเป็นแบบ Denormalized หรือไม่ก็ต้องเขียนโปรแกรมเพื่อ JOIN เอง!!!

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

ของใหม่มันก็ดีอยู่หรอกนะ แต่ยังไงเราก็ต้องใส่ใจกับของเก่าด้วย เพราะต้นทุนในการยกระดับให้ทันสมัย มันแพงเอาเรื่องอยู่เหมือนกันนะเออ

ทีนี้ถ้าเปลี่ยนใหม่ล่ะ เปลี่ยนเป็นว่าความสัมพันธ์ของตารางถูกวาดออกมาแล้ว แล้วเราต้องมาอธิบายความสัมพันธ์ดังกล่าวให้อยู่ในรูปของการพรรณนาแทน แบบนี้จะทำไงดี … งั้น มาลองดูกันดีกว่า

โจทย์ – จงอธิบายภาพความสัมพันธ์ของตารางในภาพข้างล่างพอสังเขป

กดเพื่อดูภาพขยาย

ตอบ

1. พลเมืองทุกคนต้องจดทะเบียนสมรส จึงถือว่าการสมรสเกิดขึ้นอย่างสมบูรณ์
2. ไม่มีการจำกัดเพศในการสมรส ซึ่งแปลว่าเพศเดียวกันจะสมรสกันเองก็ได้
3. ไม่มีการจำกัดว่าการสมรสจะต้องเกิดจากบุคคลสองคน อาจจะเกิดจากบุคคลเดียว หรือสามบุคคลขึ้นไปก็ได้
4. บุตรธิดาที่เกิดจากการสมรสซึ่งจดทะเบียนฯ ถึงจะมีสิทธิ์ได้รับสูติบัตร
5. พลเมืองสามารถสมรสซ้อนได้ และสามารถจดทะเบียนสมรสเกินกว่าหนึ่งครั้งได้
6. วันที่ในการสมรส ไม่จำเป็นต้องเป็นวันที่ ๆ จดทะเบียนสมรส
7. เพศอาจมีเพียงเพศเดียว หรือมีได้มากกว่าสองเพศขึ้นไป
8. ฯลฯ

อือม ถ้าแต่ล่ะคนที่ได้โจทย์ไป ตอบไม่เหมือนกันเลย แล้วแบบนี้จะถือว่าใครถูกล่ะเนี่ย? T-T

[tags]ฐานข้อมูล, ย้อนกลับ[/tags]

ทีนี้ที่จะเล่าให้อ่านกันก็คือการทำ Data Dictionary ซึ่งเป็นสิ่งที่ผมไม่ค่อยจะถนัดเท่าไหร่ เนื่องจากทุกวันนี้ผมยังท่องกฎของ Database Normalization ไม่ได้เลย ดังนั้น วิธีแก้ไขก็คือการใช้เครื่องมือเข้าช่วย ซึ่งเป็นโชคดีของผมที่มีผู้สาวจัดหาเครื่องมือมาให้ใช้ โดยเครื่องมือดังกล่าวมีชื่อว่า fabFORCE DBDesigner

…มันเป็นเครื่องมือทุ่นแรงที่ดี เพราะถ้าไม่มีมัน การออกแบบ Data Dictionary คงสาหัสขึ้นอีกอักโข แถมข้อดีอีกอย่างหนึ่งของมันก็คือ มันสนับสนุน MySQL ซะด้วยสิ ยิ่งดีเข้าไปใหญ่!!!

แต่เหนือสิ่งอื่นใด การออกแบบ Data Dictionary ก็ยังคงขึ้นกับจินตนาการของผู้ออกแบบอยู่ดี ดังนั้น ต่อให้มีเครื่องมือดีแค่ไหนก็ตาม .. แต่ทว่า .. หากจินตนาการของเราตีบตัน เครื่องมือก็ย่อมจะไม่สามารถช่วยเหลืออะไรเราได้อยู่ดี!

[tags]เครื่องมือ, ออกแบบ, data, dictionary, fabFORCE, DBDesigner[/tags]

ถ้าอยากจะใช้ฐานข้อมูล MySQL ก็สามารถจะติดตั้งลงใน Amazon EC2 ได้ .. แต่ .. ต้องลงตัว MySQL Enterprise นะเอ้อ! แล้วก็ต้องจ่ายตังค์ให้กับความ Enterprise ของมันด้วย T-T ซึ่งคิดว่าคงไม่น้อย (ยังไม่ได้ตรวจราคา)

แต่ถ้าไม่อยากจ่าย อยากจะใช้ Amazon SimpleDB ก็ได้ แต่งานนี้รับรองหลังแอ่นแน่ ๆ เพราะ Amazon SimpleDB มันไม่ได้เป็น RDBMS มันก็เลยไม่มีอะไร ๆ ที่ RDBMS ทั่ว ๆ ไปเขามี ซึ่งสิ่งที่ขาดหายไปและถือว่าร้ายแรงที่สุดก็คือ มันไม่มี INDEX อ่ะดิ! แล้วจะให้ทำ RDBMS เองเหรอ อือม ไม่เอาอ่ะ ทำไม่เป็น T-T

ตอนนี้ Amazon SimpleDB ยังเป็น BETA อยู่ หวังลึก ๆ ว่าเขาคงจะทำ INDEX ในรุ่นจริงออกมานะ เพราะถึงแม้จะ join table ไม่ได้ แต่อย่างน้อย ขอค้นแบบเร็ว ๆ ได้ก็ยังดี

[tags]ฐานข้อมูล, Amazon, S3, EC2, SimpleDB[/tags]

ดังนั้นหากเราไม่อยากจะเจอกับเรื่องเลวร้ายเช่นนี้ งั้นเรามาทราบกฎกันดีกว่า ว่าเราควรจะทำยังไงกันดี?

กฎข้อแรก อย่าออกแบบตามหลักการ Normalization

• เพราะการแยกข้อมูลกระจายไว้ตาม table ต่าง ๆ ตามหลักการ Normalization นั้น มันดูดี๊ดูดีในทางทฤษฎี แต่มันใช้ไม่ได้เลยในทางปฏิบัติ โดยเฉพาะหากต้อง join table เยอะ ๆ ซึ่งมีข้อมูลมาก ๆ หรือใช้ subquery แล้วล่ะก็ … ไอ้ Normalization เนี่ยแหล่ะ มันจะรัดคอตัวมันเอง

กฎข้อสอง อย่าเลือกข้อมูลเกินความจำเป็น

• ยกตัวอย่างเช่น select * from person โดย table ชื่อ person มีฟิลด์เป็นร้อย แต่ดันใช้แค่ฟิลด์ id กับ name … งั้นก็เปลี่ยนเป็น select id, name from person ดีกว่ามั๊ง!!

กฎข้อสาม ระบุ index ให้ชัดเจนไปเลย

• ตามหลักแล้ว table ทุกอันควรมี primary key และ index เพื่อความรวดเร็วในการค้นหา ซึ่งบาง table อาจจะมี index มากกว่าหนึ่งตัว งั้นแทนที่เราจะเขียนว่า select id, name from person where name = “ยิปซี” เราก็ระบุเป้ง ๆ ไปเลยว่าเราจะใช้ index ตัวไหน เช่น select id, name from person where name = “ยิปซี” use index (ix_name) เป็นต้น

กฎข้อสี่ อย่ายึด table ไว้คนเดียว

• ไอ้เจ้า table ก็เปรียบได้กับสมบัติ มันต้องผลัดกันชม ดังนั้นการยึดเอาไว้ select แค่คนเดียวมันก็เกินไป เพราะมีคนอื่นเข้าแถวรอ select อยู่ จะเป็นการทำให้ชาวบ้านเขาเสียเวลาได้ งั้นที่ถูกต้องก็คือ พอ select ได้แล้วก็รีบ ๆ ลอกเอาไปไว้อีกที่นึง จากนั้นก็เชิญไปคุ้ยแคะข้อมูลที่เลือกไปได้ตามสบาย โดยการ select sql_buffer_result id, name from person where name = “ยิปซี” แบบนี้

กฎข้อห้า ต้องรู้จักการ Recycle

• ข้อมูลบางชุดมีคนต้องการเยอะ ไอ้ครั้นจะให้ฐานข้อมูลค้นซ้ำ ๆ มันก็เปลืองแรงไป งั้นค้นทีเดียวเก็บเอาไว้ แล้วแจกจ่ายให้คนที่ต้องการภายหลังดีกว่า โดยการ select sql_cache id, name from person where name = “ยิปซี” เป็นต้น

กฎข้อหก เอากฎข้อหนึ่งถึงกฎข้อห้ามารวมกัน

• ก็จะได้แบบนี้ select sql_buffer_result sql_cache id, name from person where name = “ยิปซี” use index(ix_name)

แต่กฎย่อมไม่มีความตายตัว ดังนั้นกฎใหม่ย่อมจะสามารถแทนที่กฎเก่าได้เสมอ ดังนั้นถ้าใครทำให้มันเร็วกว่านี้ได้ ก็ไม่ต้องเชื่อกฎนี้ก็แล้วกันนะจ๊ะ

[tags]กฎ, select, ข้อมูล, table, ขนาดใหญ่, ฐานข้อมูล, mysql[/tags]

ขั้นตอนการ Import ไฟล์ UTF-8 เข้าฐานข้อมูล MySQL ด้วย phpMyAdmin

1. เปิด Notepad++ แล้วเลือกเข้ารหัสเป็น “UTF-8 without BOM”
2. สำเนาข้อมูลจาก Microsoft Excel มาใส่ไว้ใน Notepad++ แล้วบันทึก
3. สร้างโครงสร้างตารางแบบ UTF-8 เตรียมไว้ในฐานข้อมูลด้วย phpMyAdmin
4. ทำการ Import ไฟล์ UTF-8 without BOM ที่บันทึกเอาไว้เข้าฐานข้อมูล MySQL
5. โดยบอกมันว่าไฟล์ที่จะนำเข้า เป็นไฟล์ที่เข้ารหัสแบบ Latin1 หรือ Cp1252 (ยุโรปตะวันตก)
6. พอ Import เข้าไปแล้วก็เป็นอันเรียบร้อย ได้เรคคอร์ดในตารางที่เข้ารหัสแบบ UTF-8 เป๊ะ ๆ

เชื่อว่าเป็นการเอามะพร้าวห้าวมาขายสวน แต่จะทำยังไงได้ล่ะ คนเรามันไม่รู้กันไปหมดทุกอย่างนี่นา อิ อิ

[tags]import, utf-8, phpMyAdmin, MySQL, ฐานข้อมูล[/tags]

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

ผมมีสถิติอะไรที่น่าสนใจมาให้ดู สถิตินี้ได้จากการที่ผมมักจะเอา open source ดัง ๆ มาติดตั้งที่เครื่องเพื่อทดสอบเล่นอะไรโน่นนี่อยู่บ่อย ๆ

เราจะมองว่าการที่ open source ตัวใดต้องใช้ table เยอะแล้วมันคือ open source ที่ซับซ้อนได้ป่ะ? อือม จะบอกงั้นก็ไม่ได้ ถ้าบอกแบบนั้นงั้นก็แสดงว่า CakePHP กับ WordPress ไม่ซับซ้อนอ่ะดิ!!!

ไม่หรอก!! จะบอกแบบนั้นไม่ได้หรอก จริง ๆ แล้วความซับซ้อนต้องจำกัดความให้มันกระชับกว่านั้น นั่นก็คือผมคิดว่าการที่ open source ตัวใดต้องใช้ table เยอะ นั่นก็น่าจะหมายความว่า open source ตัวดังกล่าว จำเป็นที่จะต้องเก็บสารสนเทศอันซับซ้อนซะมากกว่า

ป.ล. 1 – ผมขี้เกียจจับภาพใหม่ ผมเพิ่งเห็นว่า WordPress ที่ผมลงไว้ มันมี Table เกินมา 6 Table อันเกิดจาก Plugins จริง ๆ ต้องมีแค่ 10 Table เท่านั้น
ป.ล. 2 – Drupal มันแน่จริง ๆ เลยครับ มี Table มากกว่า Joomla ซะอีก!!!

[tags]CakePHP, Druppal, Joomla, MediaWiki, MySQL, phpBB, PhpMyAdmin, WordPress, คอมพิวเตอร์,ซอฟต์แวร์,open source, table, code[/tags]

เรื่องของเรื่องก็คือโฮสติ้งที่ผมเช่าอยู่นี่แหล่ะ มันมักจะมีอะไรแปลก ๆ เสมอ ดูเหมือนโฮสติ้งเมืองไทยจะมีอะไรแปลก ๆ บ่อย เอ หรือว่าผมจะแปลกเองวะเนี่ย

ปัญหาที่ผมเจอคือ มันไม่รับคำสั่ง SQL ของผมครับ ซึ่งมันเป็นคำสั่งที่เรียบง่ายมาก ดังต่อไปนี้

select member_id, name from member where member_id = (select max(member_id) from member)

ทำที่ localhost ก็ผ่าน ทำที่ไหน ๆ ก็ผ่าน แต่ถ้าเป็นโฮสติ้งที่ผมเช่าเพื่อวางบล็อกนี้ มันไม่ผ่าน เอ้อ แปลกดี!!!

นี่มันคำสั่งอันแสนจะพื้นฐานเลยนะเนี่ย

ป.ล. หรือว่า mysql รุ่น 4.0.21 มันไม่รับคำสั่งพื้น ๆ แบบนี้?

[tags]SQL,อัศจรรย์,คอมพิวเตอร์,ซอฟต์แวร์,การสร้างซอฟต์แวร์,SaaS, Software as a Service[/tags]

จะมีก็แต่ระบบปฏิบัติการ และโปรแกรมเอกสารสำนักงานอย่าง Word, Excel หรือ PowerPoint เท่านั้นกระมัง ที่ไม่ต้องต่อเชื่อมฐานข้อมูล!!!

ที่ ๆ เก็บข้อมูลก็คือฐานข้อมูล ในทางคอมพิวเตอร์นั้น ยักษ์ใหญ่ทางด้านซอฟต์แวร์จัดการฐานข้อมูลก็มีหลายเจ้า ผมเองเคยใช้ไม่กี่อย่าง ที่เคยใช้มีก็เช่น Oracle, Informix, Sybase, Progress, SQL Server และ MySQL

หากเราเคยเรียนวิชาฐานข้อมูลมา เราจะพบว่าถึงแม้เราจะไม่ได้ท่องทฤษฎีความสัมพันธ์ ของการเชื่อมโยงข้อมูลในฐานข้อมูลมาแบบเป๊ะ ๆ ก็ตาม แต่โดยสัญชาติญาณของคนคอมพิวเตอร์ ก็สามารถที่จะออกแบบตารางข้อมูล เพื่อเอาไว้ใช้เก็บข้อมูลได้ อย่างคร่าว ๆ

นั่นย่อมแสดงว่าคนที่เรียนจบคอมพิวเตอร์มา ส่วนใหญ่ล้วนสามารถออกแบบฐานข้อมูลเองได้ ตามความต้องการที่ได้รับมา!!!

ทีนี้เมื่อออกแบบมาแล้ว เคยคิดกันมั้ยครับว่าฐานข้อมูลของเรานั้น จะมีอัตราการเติบโตอยู่ที่เท่าไหร่ และเราควรจะใช้เนื้อที่ของ Hard Disk เป็นจำนวนเท่าไหร่สำหรับเก็บข้อมูล หรือใช้ CPU และ RAM เท่าไหร่ สำหรับรองรับการค้นหาข้อมูลภายในฐานข้อมูลของเรา???

ตัวแปรย่อมมีเยอะมาก หากต้องมีการคำนวณกันจริง ๆ เพราะตารางแต่ล่ะตารางในฐานข้อมูล ย่อมมีอัตราการเติบโตที่แตกต่างกัน ตามแต่สถานการณ์การใช้งาน อีกทั้งเพื่อเพิ่มความรวดเร็วให้กับการค้นข้อมูล ก็จำเป็นที่จะต้องมีการสร้าง Index เพื่อไว้ชี้ข้อมูลในตารางข้อมูลอย่างฉับไวอีกด้วย

ซึ่งสิ่งเหล่านี้ล้วนต้องทำให้เสียพื้นที่ใน Hard Disk ทั้งสิ้น!!!

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

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

[tags]คอมพิวเตอร์,sizing,ฐานข้อมูล,คำนวณ,การจัดการฐานข้อมูล[/tags]

ลูกค้าขององค์กรที่ผมทำงานอยู่มีมากมายครับ ในแต่ล่ะวันมีเข้ามาจำนวนราว 8,000 คนขึ้นไป ดังนั้นการออกใบเสร็จรับเงินจึงถือเป็นเรื่องสำคัญสุดขีดครับ เพราะออกใบเสร็จได้ก็แสดงว่าได้รับเงินเข้ากระเป๋าอย่างสมบูรณ์นั่นเอง และถ้าออกไม่ได้ แสดงว่าองค์กรจะสูญเสียเงินรายได้ถึงวันล่ะ 20 ล้านบาท!!!

ทีนี้เรื่องยุ่ง ๆ มันก็อยู่ตรงที่ผมได้รับมอบหมายให้มาตรวจสอบว่าทำไมออกใบเสร็จรับเงินล่าช้า แต่ผมต้องควานหาครับ ว่าต้นตอนั้นเกิดจากที่ใด แถมต้องรายงานความคืบหน้าด้วยว่าดำเนินการยังไงไปบ้างแล้ว

ประเด็นมันอยู่ที่ระบบ Billing ดังกล่าว มีทีมงานดูแลอยู่ก่อนแล้วและมันไม่ใช่ระบบที่ผมดูแลอยู่ โดยทีมงานดังกล่าวประกอบไปด้วยนักพัฒนาซอฟต์แวร์ 4 – 5 คนและนักวิเคราะห์ระบบ 1 คน

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

จากการประชุมทำให้ผมได้ทราบว่าปัญหาไม่น่าจะเกิดขึ้นทางระบบ hardware หรือระบบ network แต่น่าจะมาจากฐานข้อมูล เพราะทางทีม System Admin แจ้งว่า CPU Time ของ Database Server ขึ้นสูงถึง 100% ตลอดมาตั้งแต่เริ่มเกิดปัญหาแล้ว อีกทั้ง Virtual Memory ก็ใช้เกิน 70% อีกด้วย ถือได้ว่าวิกฤติมาก

ผมจึงตั้งประเด็นไปที่ data dictionary ของระบบ Billing ครับ ว่ามีการกำหนด index กันอย่างถูกต้องหรือเปล่า โดยขอให้ทีมงานชี้แจงให้ผมทราบครับ ว่าฐานข้อมูลที่ใช้มีรายละเอียดใด ๆ บ้างซึ่งได้รับคำตอบมาดังนี้ครับ

• ฐานข้อมูลทำงานบน Microsoft Windows 2003 วิ่งอยู่บน Clustering
• ฐานข้อมูลที่ใช้เป็น Microsoft SQL Server
• ในฐานข้อมูลดังกล่าวมี Table ที่เกี่ยวกับระบบ Billing ราว ๆ 30 Table
• มี Table ที่มีข้อมูลเกิน 10,000,000 เรคคอร์ดอยู่ราว 10 Table
• มีการ join table กันตามหลักการของฐานข้อมูล (ยั้วเยี้ยไปหมด)

ตอนแรกผมตั้งประเด็นไปที่ index ครับ จึงขอให้ทางทีมงานแจ้งแก่ผมว่า table ใหญ่ ๆ ที่ใช้อยู่เป็นประจำทุกวันนั้น มีรายละเอียด index อย่างไรบ้าง

จากการวิเคราะห์ของผมพบว่า การกำหนด index เป็นไปอย่างถูกต้องและสมบูรณ์ตามหลักการเชื่อมโยง Table ครับ ไม่น่าจะทำให้เกิดการล่าช้าใด ๆ ผมจึงเปลี่ยนประเด็นไปที่โค้ดโปรแกรมของระบบ Billing ครับ จึงขอให้ทีมงานให้สิทธิ์ในการเข้าสู่ Source Code Server เพื่อให้ผมเข้าไป Check In ดู Source Code ได้

Source Code ของระบบ Billing มีขนาดใหญ่โตมากครับ ประกอบไปด้วยฟอร์มเป็นร้อยฟอร์ม และรายงานเป็นร้อย ๆ ตัว แถมมีระบบ Enhance หลาย ๆ อย่างด้วย

ผมพุ่งเป้าไปที่ Source Code ในส่วนของการพิมพ์ใบเสร็จรับเงินทันทีครับ และในที่สุดผมก็พบชุดคำสั่งราว ๆ 5 บรรทัดครับ ซึ่งเป็นตัวสร้างปัญหา มันเป็นงี้ครับ

Dim rs as new ADODB.recordset

rs.CursorLocation = adUseServer

rs.LockType = adOpenStatic

rs.CursorType = adLockOptimistic

set rs = con.execute(str)

ถึงผมจะรู้ Visual Basic 6.0 ไม่มากนั้น แต่ก็พอดูออกครับ ว่าโค้ดซึ่งกำหนดการล็อกฐานข้อมูลมันแม่ง ๆ ก็เลยค้นจาก msdn ดูก็อธิบายโค้ดดังกล่าวได้ดังนี้ครับ

• ให้ใช้ CPU และ Virtual Memory แต่ที่ฝั่ง Database Server ทางฝั่ง Client ไม่รับรู้และไม่ช่วยอะไร Database Server ทั้งสิ้น
• ทุกครั้งที่จะค้นข้อมูล ให้จองผืนหน่วยความจำขนาดใหญ่ ไว้ที่ Database Server เพื่อให้เวลาอ่านข้อมูล สามารถอ่านเรคคอร์ดเดินหน้าและอ่านเรคคอร์ดถอยหลังได้
• ให้ล็อก Table เอาไว้ ไม่แบ่งให้ใคร ณ ตอนนั้น ถึงจะล็อกเพื่อแสดงผลอย่างเดียวก็ตาม โดยให้ล็อกเต็มรูปแบบ เพื่อเพิ่ม, ลบ และปรับปรุงข้อมูล

ผมจึงสอบถามทีมงาน Billing ครับ ว่าการออกใบเสร็จรับเงินเนี่ย ในระหว่างที่กำลังค้นข้อมูล มีการ update ข้อมูลไปด้วยหรือไม่? คำตอบคือไม่, แล้วมีการอ่านข้อมูลเดินหน้าถอยหลังหรือไม่? คำตอบคือไม่ อ่านเดินหน้าเพียงอย่างเดียวเท่านั้น และสุดท้ายจึงถามว่าสเป๊กเครื่องของ User ซึ่งกระจายอยู่ในองค์กรทั้งหมดราว 300 กว่าเครื่อง เป็นสเป๊กเครื่องระดับไหน ก็ได้รับคำตอบว่าเป็น CPU 1.2 GHz

เมื่อได้รับคำตอบอย่างนี้แล้ว ผมจึงเข้าใจทันทีว่า ทำไมระบบจึงล่าช้า, ทำไม CPU และ Virtual Memory บน Database Server ถึงถูกใช้จนเปอร์เซ็นต์ขึ้นสูง

ผมจึงสั่งการให้ทีมงานพัฒนาซอฟต์แวร์ของระบบ Billing ทุกคน แก้โค้ดในส่วนของการอ่านข้อมูลจากฐานข้อมูลที่ตนเองรับผิดชอบอยู่ทั้งหมดโดยด่วน โดยให้แก้เป็นดังนี้ครับ

Dim rs as new ADODB.recordset

rs.CursorLocation = adUseClient

rs.LockType = adForwardOnly

rs.CursorType = adLockReadOnly

set rs = con.execute(str)

ซึ่งสิ่งที่ผมให้ทีมงานพัฒนาซอฟต์แวร์ของระบบ Billing แก้ไข อธิบายความหมายได้ดังนี้ครับ

• ให้ใช้ CPU และ Virtual Memory แต่ที่ฝั่ง Client ด้วย ไม่ใช่ให้ทุกอย่างไปโหลดอยู่ที่ Database Server แต่เพียงอย่างเดียว
• ไม่ต้องจองผืนหน่วยความจำ เพราะการอ่านข้อมูลทำเพื่ออ่านเรคคอร์ดแบบเดินหน้าเท่านั้น ไม่ได้อ่านเรคคอร์ดแบบถอยหลังด้วย ดังนั้นไม่ต้องจองผืนหน่วยความจำที่ Database Server ให้เกินความจำเป็น
• อย่าล็อก Table แบบเต็มรูปแบบ เพราะแค่อ่านอย่างเดียว ดังนั้น ล็อกแบบอ่านอย่างเดียวก็พอ Client อื่นจะได้เข้าใช้ Table เดียวกันได้ด้วย

ภายหลังแก้โค้ดโดยเลือกแก้ไขในฟอร์มและรายงานที่ถูกใช้บ่อย ๆ ซึ่งทุกคนใช้เวลาแก้ไขกันราว 10 นาที ผมก็ตรวจสอบการทำงานของระบบอีกครั้ง แล้วจึงอนุมัติให้ทีมงาน build ทั้ง project ขึ้นสู่ Application Server

จากนั้นจึงติดต่อให้ User ซึ่งประจำการอยู่กับ Client ทั้ง 300 กว่าเครื่อง ให้เริ่มลองใช้ซอฟต์แวร์ แล้วก็พบผลลัพท์ที่น่ายินดีครับว่า Client ทั้งหมดที่เคยเข้าถึงระบบอย่างล่าช้า แถมพิมพ์ใบเสร็จใบนึงต้องใช้เวลาถึง 2 นาที กลับทำงานได้อย่างรวดเร็ว โดยใช้เวลาเพียง 12 วินาทีเท่านั้นในการอ่านข้อมูล

เมื่อทราบวิธีการแก้ไขแล้ว ผมจึงสั่งการให้ทีมพัฒนาฯแก้ไขโค้ดส่วนที่เหลือทั้งหมด ให้สอดคล้องกับรูปแบบการแก้ปัญหาที่ได้เคยวางเอาไว้ครับ เพื่อให้มันทำงานได้เร็วกว่า 12 วินาที

จากปัญหานี้ทำให้ทราบอย่างนึงว่า ถ้าเราเขียนซอฟต์แวร์เพียงคนเดียว, มีผู้ใช้ซอฟต์แวร์ของเราเพียงคนเดียวและ ต่อเชื่อมเข้าฐานข้อมูลเพียง Client เดียว เราจะเขียนให้ล็อก Table กันยังไงก็ได้ครับ ไม่ต้องใส่ใจ แต่ถ้าเมื่อไหร่เราต้องเขียนซอฟต์แวร์ร่วมกับทีมงานอีกหลายคน , มีผู้ใช้ซอฟต์แวร์ของเราเป็นร้อย ๆ คนและต่อเชื่อมเข้าฐานข้อมูลโดย Client เป็นร้อย ๆ เครื่องล่ะก็

ได้โปรดพิจารณารายละเอียดการล็อก Table ให้จงหนักครับ เพราะนั่นเป็นบทบาทของนักพัฒนาซอฟต์แวร์ ไม่ใช่นักวิเคราะห์ระบบครับ