CMS ที่ผมต้องการ (ตอนที่ 2): ความต้องการส่วนตัว

วันพฤหัส 11 พฤศจิกายน พ.ศ. 2547 04:20:39

จากที่ได้เขียนตอนที่ 1 ไปแล้ว เกี่ยวกับนิยามของคำว่า CMS ในมุมมองของผม วันนี้ผมก็จะขอพูดถึงสิ่งที่ผมต้องการให้เพื่อนๆได้ฟังว่า ระบบ CMS ที่ผมอยากได้ ควรจะมีอะไรบ้าง ซึ่งผมจะขอพูดแบบกว้างๆก่อนนะครับ ยังไม่ขอลงลึกลงไปว่า จะใช้เทคโนโลยีอะไรเข้ามาสร้าง อย่างไร เพราะผมเองก็ยังไม่ได้ลงมือสร้างมันจริงๆเลย ที่เขียนเรื่องนี้ขึ้นมาก็เพราะต้องการหาเพื่อนๆที่สนใจในแนวทางเดียวกัน มาช่วยกันสร้าง เพราะลำพังผมคนเดียวคงจะพัฒนาระบบนี้ออกมาได้ยาก (ก็เล่นฝันไว้ไกลเกิน :) ) ขอเริ่มเลยนะครับ

----------

2. ความต้องการส่วนตัว

2.1 ที่เก็บข้อมูล

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

เมื่อหลายปีก่อน ผมจึงได้ตั้ง server ขึ้นมาในที่ทำงาน เพื่อเก็บคลังข้อมูลของผม และสามารถเรียกใช้งานจากที่ไหนก็ได้ โดยดึงข้อมูลเหล่านี้ ผ่านอินเตอร์เน็ตมา แต่แล้วก็ประสบปัญหาเกี่ยวกับเรื่องความปลอดภัย เพราะเกรงว่าจะเกิดช่องโหว่ให้นักเจาะระบบ หรือไวรัส เข้ามาสร้างความเสียหายได้ ที่ทำงานผมจึงปิดกั้นด้วย firewall และไม่อนุญาติให้มี server ส่วนตัว ตอนนั้นผมก็แก้ปัญหาด้วยการซื้อ external harddisk แล้วแบกมันไปด้วยเสมอ จะทำงานที่ไหนก็เสียบ USB ใช้ได้เลย แต่ external HD ที่ผมซื้อมาตอนนั้นก็ไม่ใช่เบาๆ เป็นแบบ 3.5" รวมทั้งอแด็ปเตอร์ด้วย (สมัยนั้นยังไม่มีแบบเล็กๆพกพาสะดวกเหมือนสมัยนี้) จะไปไหนก็ต้องระวังไม่ให้กระเทือนมาก กลัวว่าข้อมูลจะเสียหาย แต่ตอนนี้ ผมกำลังเล็งๆว่าจะซื้อตัวใหม่ที่เล็กและเบามากขนาด HD 2.5" นะครับ หรืออาจจะเป็นแบบ 1.8" ก็ได้ แต่ว่ายังมีราคาแพงอยู่มาก

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

2.2 การจัดหมวดหมู่ข้อมูล

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

แต่เนื่องจากว่า ผมเก็บข้อมูลไว้เป็นไฟล์ปกติ การที่จะ copy ข้อมูลไว้ในแต่ละโฟลเดอร์ที่เราจัดแบ่งตามประเภทไว้ จะทำให้เกิดความซ้ำซ้อน และสิ้นเปลืองเนื้อที่จัดเก็บเป็นอย่างมาก นอกจากนี้ยังทำให้การ update ทำได้ยากขึ้นด้วย ผมจึงใช้วิธีสร้างลิ้งค์ขึ้นมาแทน แต่ว่า แต่ละ platform จะมีวิธีการจัดการกับลิ้งค์ที่แตกต่างกัน เช่น ระบบปฏิบัติการ Windows สามารถสร้าง Shortcut ขึ้นมา แต่ระบบ Unix/Linux จะสร้าง symlink ไฟล์ ซึ่งการทำแบบนี้ จะทำให้ค่อนข้างยึดติดกับ platform อย่างมาก ทำให้ไม่สะดวกในการใช้งานข้าม platform เท่าที่ควร นอกจากนี้ จะมีปัญหาภายหลังถ้าหากเราต้องการย้ายที่เก็บจาก platform หนึ่งไปอีก platform หนึ่ง ผมจึงต้องการระบบที่ไม่ทำให้เกิดไฟล์ซ้ำซ้อนสิ้นเปลืองเนื้อที่ และจะต้องไม่ขึ้นอยู่กับ platform ใดๆ

2.3 การสำรองข้อมูล

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

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

2.4 การปรับปรุงให้ทันสมัย

การปรับปรุงข้อมูลให้ทันสมัยนั้น ผมหมายถึงการกระทำใดๆกับข้อมูล ไม่ว่าจะเป็น สร้าง (create), แทรก (insert), ลบ (delete), เปลี่ยนชื่อ (rename), ย้าย (move), แก้ไข (edit), แปล (compile, translate), ประมวลผล (execute, run), การแสดงผลในรูปแบบต่างๆ (view, report) ฯลฯ และเนื่องจากระบบนี้ควรจะสามารถจัดการกับข้อมูลได้หลายประเภท ซึ่งข้อมูลแต่ละประเภท จะมีลักษณะโครงสร้างที่แตกต่างกันไป การกระทำใดๆกับข้อมูลแต่ละประเภทนั้น ก็จะแตกต่างกัน ซึ่งเราไม่สามารถสร้างโปรแกรมเพียงตัวเดียวให้ครอบคลุมกับข้อมูลทุกประเภท ทั้งที่รู้จักในปัจจุบัน และอาจจะมีเพิ่มขึ้นในอนาคตได้ ดังนั้น ระบบควรจะสามารถเพิ่มเติมชนิดของข้อมูล และเพิ่มเติมความสามารถในการจัดการกับข้อมูลแต่ละประเภทได้ และควรจะทำได้ง่ายๆโดยไม่จำเป็นต้องแก้ไขโปรแกรมทั้งระบบ ด้วยการใช้หลักการ plug-in โมดูลต่างๆเข้าไปได้

นอกจากนี้ เมื่อมีการปรับปรุงข้อมูลแล้ว ระบบควรจะสามารถจัดเก็บข้อมูลอันเก่าไว้ เพื่อให้สามารถย้อนกลับมาใช้ข้อมูลเดิมหากเกิดข้อผิดพลาดได้ โดยอาจจะมีการจัดทำรุ่นและบันทึกสถานะไว้ (Versioning) ซึ่งความจริงแล้ว ความสามารถนี้อาจจะไม่จำเป็นมากนักสำหรับการใช้งานแบบคนเดียวและมีที่เก็บข้อมูลที่จุดเดียว แต่หาก ระบบขยายใหญ่ขึ้น โดยกระจายที่เก็บข้อมูลออกไป และอาจจะมีการแบ่งปันข้อมูลเพื่อใช้งานร่วมกัน การจัดทำรุ่นและบันทึกสถานะไว้ (หมายเหตุ, วัน-เวลา, ผู้ปรับปรุง ฯลฯ) จะช่วยให้การปรับปรุงข้อมูลให้ทันสมัยตรงกัน (Synchronization) ทำได้สะดวกขึ้น

2.5 การค้นหาข้อมูล

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

และเพื่อให้ระบบค้นหามีประสิทธิภาพ ระบบควรจะสามารถเลือกกลุ่ม, หมวดหมู่ หรือชนิดที่จะค้นหาได้ ตั้งแต่ระดับหยาบ ไปจนกระทั่งละเอียด

----------

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

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

since September 2002
Web Counter by http://www.digits.com
Last updated : Sunday, 14 November, 2004 12:24

Copyright © 2002-2004 Somchai LIMSIRORATANA. All rights reserved.