รบกวนเซียน it ปรึกษาเรื่องกล้องวงจรปิดหน่อยครับ

[naisomchai]

นายสมชายลองไปหา database MUMPS เล่นดูครับ ไม่support SQL ครับ ฮาฮา

เพิ่งรู้จักระบบฐานข้อมูลที่ว่าเนี่ยแหละครับ เลยค้นได้ข้อมูลตามลิ้งก์นี้ที่พอสรุปได้เร็วที่สุด... http://healthcaresecurity.wordpress.com/2010/10/12/why-are-hierarchical-databases-like-mumps-still-popular-in-healthcare/ ...

ประเด็นคือ MUMPS เป็นระบบฐานข้อมูลแบบ Hierarchical databases ในขณะที่ SQL เป็นแบบ Relational database management system : RDBMS ... เลยถึงบางอ้อ...

สรุปความได้ว่าที่มันนิยมในโรงบาลฯ กับในสถาบันการเงินมาตั้งแต่สมัย 20 กว่าปีที่แล้วก็เพราะ RDBMS เจอปัญหา 2 อย่างที่คนสมัยโน้นแก้ไม่ตกก็คือ 1) เรื่องความเข้าใจการออกแบบตรรกะข้างใน RDBMS ขยายความได้ว่าเป็นเรื่องของการเขียนสคีม่า(Schema  - Logical design) หรืออธิบายให้นักคอมพิวเตอร์เข้าใจง่ายๆ ก็คือการนอมอลไลเซชั่น(Normalization) ได้แก่การออกแบบตารางและความสัมพันธ์ระหว่างตารางข้อมูลข้างในระบบฐานข้อมูล...

เรื่องข้อที่ 1 นี่เป็นปัญหาจริงๆ แม้แต่ปัจจุบันนี้ก็มีปัญหาว่าออกแบบกันไม่ได้ง่ายๆ แต่ที่จริงแล้วเรื่องมันง่ายมากหากทิ้งเรื่อง NF1-NF3 ให้หมด แล้วท่องเอาไว้ในใจว่า"อะไรของอะไรให้มันอยู่ด้วยกัน"... เพียงแค่นี้ก็จะได้ Entity ไล่เรียงเป็นรายการยาว และกลายเป็นคอนเซ็ปต์ของ OOP ไปเสียเลยในคราวเดียวกันนั่นแหละ แล้วจากนั้นก็ลาก Key Field เอาจากด้านหัวไปแปะไว้ในตารางด้านหาง(จาก 1 ไปแปะที่ Many) ซึ่งไม่น่าเชื่อว่าแค่ประโยค 2 ประโยคที่ว่านี่สามารถ"ลากยาว"เป็นหนึ่งวิชา 3 หน่วยกิตในมหาลัยมาตรฐานฯ... ไม่ฮา...

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

เรื่องที่ 2 คือข้อจำกัดของฮาร์ดแวร์สมัยก่อน ที่มีเม็มโมรี่จำกัด และมี CPU ทำงานช้า, ตัวอย่างเช่นอยากรู้ว่าผู้ป่วยในระบบฐานข้อมูลจำนวน 1 แสนคนมีใครเป็นโรคหวัดนกบ้าง ซึ่งเราไปค้นข้อมูลอย่างนี้ใน RDBMS นั่นก็แปลว่าเครื่องคอมฯ จะต้องโหลดตาราง"ผู้ป่วย"ทั้งแสนคนมาในเม็ม(หรือตารางข้อมูลชั่วคราว) แล้วโหลดตาราง"โรค"ทั้งหมดเข้ามาด้วย จากนั้นก็ไล่เช็ค Key field ว่าของใครมันตรงกัน แล้วก็ดีดเรคคอร์ด Output ไปใส่ในอีกตารางชั่วคราวไว้แสดงผลลัพธ์... แต่ตรงกันข้ามหากจัดเก็บข้อมูลไว้ในรูปแบบ Hierarchical databases เครื่องคอมมันจะกวาดหา"แฟลก"โรคหวัดนกจากตาราง"ผู้ป่วย"แค่ตารางเดียว แล้วได้ผลลัพธ์ตูมเดียวเลย(ฐานข้อมูล Hierarchical databases จะยอมเก็บข้อมูลซ้ำกันได้)...

สรุปคือ Hierarchical databases มันทำงานเร็วกว่าในสมัยก่อนครับ... แต่เดี๋ยวนี้ฮาร์ดแวร์ไปไกลแล้ว และที่เขายังคงใช้งาน Hierarchical databases อยู่ ก็เพราะองค์ความรู้มันยังมีอยู่ในสายอาชีพเช่นว่านั้น และมันยังไม่ตัน เขาก็ยังใช้งานต่อไป...

แต่จะว่าไปแล้วคุณป๊อกแมนฯ นี่มหัศจรรย์กว่าครับ เพราะ"สร้างระบบฐานข้อมูล"ด้วยมือตนเองเสียเลย... เพราะจากเท่าที่ให้ข้อมูลมายังใช้ DBF อยู่, นั่นแปลว่าหากจะหาผลลัพธ์ที่เกิดความสัมพันธ์ระหว่างหลายไฟล์ DBF ก็ต้องเปิดอะเรย์ แล้วโหลดทั้งตารางมาเขียนลูปให้เลื่อนทีละเร็คคอร์ดเพื่อวนหาคีย์ฟิลด์... ซึ่งตรงนี้บอกตรงๆ ว่านายสมชายตายแหงๆ หากโดนให้บังคับเขียนโปรแกรมแบบนี้... แฮ่ๆ...

[naisomchai]

55555  จานโฉมชาย (ฮา)  รับยา   " ช่องสาม "  อ่ะ ฮา 55555 

ยายบ๊าบตาสว่าง ไปบอก"ยิ้มตาสว่าง" ให้ไปรับป๊อบคอร์นที่ช่อง 5 ได้แล้ว... ฮา...

[TakeFive]

นายสมชายลองไปหา database MUMPS เล่นดูครับ ไม่support SQL ครับ ฮาฮา

เพิ่งรู้จักระบบฐานข้อมูลที่ว่าเนี่ยแหละครับ เลยค้นได้ข้อมูลตามลิ้งก์นี้ที่พอสรุปได้เร็วที่สุด... http://healthcaresecurity.wordpress.com/2010/10/12/why-are-hierarchical-databases-like-mumps-still-popular-in-healthcare/ ...

ประเด็นคือ MUMPS เป็นระบบฐานข้อมูลแบบ Hierarchical databases ในขณะที่ SQL เป็นแบบ Relational database management system : RDBMS ... เลยถึงบางอ้อ...

สรุปความได้ว่าที่มันนิยมในโรงบาลฯ กับในสถาบันการเงินมาตั้งแต่สมัย 20 กว่าปีที่แล้วก็เพราะ RDBMS เจอปัญหา 2 อย่างที่คนสมัยโน้นแก้ไม่ตกก็คือ 1) เรื่องความเข้าใจการออกแบบตรรกะข้างใน RDBMS ขยายความได้ว่าเป็นเรื่องของการเขียนสคีม่า(Schema  - Logical design) หรืออธิบายให้นักคอมพิวเตอร์เข้าใจง่ายๆ ก็คือการนอมอลไลเซชั่น(Normalization) ได้แก่การออกแบบตารางและความสัมพันธ์ระหว่างตารางข้อมูลข้างในระบบฐานข้อมูล...

เรื่องข้อที่ 1 นี่เป็นปัญหาจริงๆ แม้แต่ปัจจุบันนี้ก็มีปัญหาว่าออกแบบกันไม่ได้ง่ายๆ แต่ที่จริงแล้วเรื่องมันง่ายมากหากทิ้งเรื่อง NF1-NF3 ให้หมด แล้วท่องเอาไว้ในใจว่า"อะไรของอะไรให้มันอยู่ด้วยกัน"... เพียงแค่นี้ก็จะได้ Entity ไล่เรียงเป็นรายการยาว และกลายเป็นคอนเซ็ปต์ของ OOP ไปเสียเลยในคราวเดียวกันนั่นแหละ แล้วจากนั้นก็ลาก Key Field เอาจากด้านหัวไปแปะไว้ในตารางด้านหาง(จาก 1 ไปแปะที่ Many) ซึ่งไม่น่าเชื่อว่าแค่ประโยค 2 ประโยคที่ว่านี่สามารถ"ลากยาว"เป็นหนึ่งวิชา 3 หน่วยกิตในมหาลัยมาตรฐานฯ... ไม่ฮา...

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

เรื่องที่ 2 คือข้อจำกัดของฮาร์ดแวร์สมัยก่อน ที่มีเม็มโมรี่จำกัด และมี CPU ทำงานช้า, ตัวอย่างเช่นอยากรู้ว่าผู้ป่วยในระบบฐานข้อมูลจำนวน 1 แสนคนมีใครเป็นโรคหวัดนกบ้าง ซึ่งเราไปค้นข้อมูลอย่างนี้ใน RDBMS นั่นก็แปลว่าเครื่องคอมฯ จะต้องโหลดตาราง"ผู้ป่วย"ทั้งแสนคนมาในเม็ม(หรือตารางข้อมูลชั่วคราว) แล้วโหลดตาราง"โรค"ทั้งหมดเข้ามาด้วย จากนั้นก็ไล่เช็ค Key field ว่าของใครมันตรงกัน แล้วก็ดีดเรคคอร์ด Output ไปใส่ในอีกตารางชั่วคราวไว้แสดงผลลัพธ์... แต่ตรงกันข้ามหากจัดเก็บข้อมูลไว้ในรูปแบบ Hierarchical databases เครื่องคอมมันจะกวาดหา"แฟลก"โรคหวัดนกจากตาราง"ผู้ป่วย"แค่ตารางเดียว แล้วได้ผลลัพธ์ตูมเดียวเลย(ฐานข้อมูล Hierarchical databases จะยอมเก็บข้อมูลซ้ำกันได้)...

สรุปคือ Hierarchical databases มันทำงานเร็วกว่าในสมัยก่อนครับ... แต่เดี๋ยวนี้ฮาร์ดแวร์ไปไกลแล้ว และที่เขายังคงใช้งาน Hierarchical databases อยู่ ก็เพราะองค์ความรู้มันยังมีอยู่ในสายอาชีพเช่นว่านั้น และมันยังไม่ตัน เขาก็ยังใช้งานต่อไป...

แต่จะว่าไปแล้วคุณป๊อกแมนฯ นี่มหัศจรรย์กว่าครับ เพราะ"สร้างระบบฐานข้อมูล"ด้วยมือตนเองเสียเลย... เพราะจากเท่าที่ให้ข้อมูลมายังใช้ DBF อยู่, นั่นแปลว่าหากจะหาผลลัพธ์ที่เกิดความสัมพันธ์ระหว่างหลายไฟล์ DBF ก็ต้องเปิดอะเรย์ แล้วโหลดทั้งตารางมาเขียนลูปให้เลื่อนทีละเร็คคอร์ดเพื่อวนหาคีย์ฟิลด์... ซึ่งตรงนี้บอกตรงๆ ว่านายสมชายตายแหงๆ หากโดนให้บังคับเขียนโปรแกรมแบบนี้... แฮ่ๆ...

สุดยอดครับ สรุปconcept รวบยอดได้ในไม่กี่ย่อหน้า นับถือเลย ชั่วโมงบินไม่ถึงทำไม่ได้ อย่างตอนที่เคยเล่าให้ฟังว่า มี mail จาก ผบห.ฝ่าย ธ.แห่งนึงขอให้ทำsqlในการ queryให้ ฟังดูอาจจะแปลกๆ แค่sql queryทำไมบุคคลากรของ ธ. ทำเองไม่ได้ จริงๆแล้วผมเล่าแค่ย่อๆ การqueryบน DB ใหญ่ๆที่มีเงื่อนไขแปลกไปจากปกติมันมีfactorที่ต้องคำนึงเยอะ แค่tableเงินฟากตัวเดียวก็เกิน10ล้านrecordแล้ว การqueryก็เลยเหมือนการเขียนโปรแกรม/function ย่อมๆขึ้นมาตัวนึง เพราะต้องคำนึงถึง perfomance และ factor อื่นๆว่าจะไม่ไปกระทบกับงานของ ธ.ด้วย เช่นตอน

แต่ขอแย้งนิดนึง เรื่องที่บอกว่า Hierarchical databases ทำงานได้ช้า ผมว่ามันเหมาะกับงานแต่ละงานมากกว่า เช่นงานที่มีDBใหญ่่ๆ table ทับซ้อน และมีover headเชิงbussinessในการแตะdatabaseเยอะๆ อย่างในงาน ธนาคาร ผมว่ามันสุดยอด(ไม่งั้นที่ บ.คงไม่implementให้ มา4 ธ.ละเนอะ) อย่างDB ดังๆ อย่าง oracle ผมเคยอ่านpaper เจอว่าระบบcore bankที่ implement บน MUMPS ทำงานได้เร็วกว่าถึง8เท่า ซึ่งในการทำงานจริง ผมลัพธ์ก็เป็นแบบนั้นจริงๆ เอาแค่งานง่ายๆ อย่าง extract ข้อมูลบน MUMPSไปแล้วให้ systemอื่นloadหรือกลับทางกัน จะพบว่าelapse time ต่างกันลิบโลก 

แต่จริงๆผมก็ไม่ได้พิศมัยกับมันมากนักหลอก จะหา tools ,lib อะไรมาเบาแรง ไม่ต้่องไปหาเลย ไม่มีหลอก มีปัญหาอะไรขึ้นมา ต้องคิดเอง แก้เอง ต้องไปค้นตำราสมัย ป.ตรี มาreview

[ป๊อกแมน]

นายสมชายลองไปหา database MUMPS เล่นดูครับ ไม่support SQL ครับ ฮาฮา

แต่จะว่าไปแล้วคุณป๊อกแมนฯ นี่มหัศจรรย์กว่าครับ เพราะ"สร้างระบบฐานข้อมูล"ด้วยมือตนเองเสียเลย... เพราะจากเท่าที่ให้ข้อมูลมายังใช้ DBF อยู่, นั่นแปลว่าหากจะหาผลลัพธ์ที่เกิดความสัมพันธ์ระหว่างหลายไฟล์ DBF ก็ต้องเปิดอะเรย์ แล้วโหลดทั้งตารางมาเขียนลูปให้เลื่อนทีละเร็คคอร์ดเพื่อวนหาคีย์ฟิลด์... ซึ่งตรงนี้บอกตรงๆ ว่านายสมชายตายแหงๆ หากโดนให้บังคับเขียนโปรแกรมแบบนี้... แฮ่ๆ...

อาจารย์ครับ ผมใช้ Query ครับ เพราะเมื่อก่อนเคยใช้แบบที่อาจารย์ว่านี่หล่ะ เกือบตายเลยครับ พอดีได้ไปอบรมเรื่อง SQL Command มาเพิ่มเติม เลยมาแปลง Code ทั้งหมดในโปรแกรมเลยครับ   

 บทสรุปที่อาจารย์สรุปมา สุดยอดเลยครับ

สำหรับเรื่องเทคนิคอื่นๆ ผมอ่อนนักครับ เทคโนโลยีก็ไม่ทัน อาศัยลูกอึดด้นสดๆไปเรื่อยๆ
ขอบคุณ ท่าน TakeFive ที่ร่วมแสดงความคิดเห็นครับ

[ค..ควาย...ใส่ชฎา]

นายสมชายลองไปหา database MUMPS เล่นดูครับ ไม่support SQL ครับ ฮาฮา

เพิ่งรู้จักระบบฐานข้อมูลที่ว่าเนี่ยแหละครับ เลยค้นได้ข้อมูลตามลิ้งก์นี้ที่พอสรุปได้เร็วที่สุด... http://healthcaresecurity.wordpress.com/2010/10/12/why-are-hierarchical-databases-like-mumps-still-popular-in-healthcare/ ...

ประเด็นคือ MUMPS เป็นระบบฐานข้อมูลแบบ Hierarchical databases ในขณะที่ SQL เป็นแบบ Relational database management system : RDBMS ... เลยถึงบางอ้อ...

สรุปความได้ว่าที่มันนิยมในโรงบาลฯ กับในสถาบันการเงินมาตั้งแต่สมัย 20 กว่าปีที่แล้วก็เพราะ RDBMS เจอปัญหา 2 อย่างที่คนสมัยโน้นแก้ไม่ตกก็คือ 1) เรื่องความเข้าใจการออกแบบตรรกะข้างใน RDBMS ขยายความได้ว่าเป็นเรื่องของการเขียนสคีม่า(Schema  - Logical design) หรืออธิบายให้นักคอมพิวเตอร์เข้าใจง่ายๆ ก็คือการนอมอลไลเซชั่น(Normalization) ได้แก่การออกแบบตารางและความสัมพันธ์ระหว่างตารางข้อมูลข้างในระบบฐานข้อมูล...

เรื่องข้อที่ 1 นี่เป็นปัญหาจริงๆ แม้แต่ปัจจุบันนี้ก็มีปัญหาว่าออกแบบกันไม่ได้ง่ายๆ แต่ที่จริงแล้วเรื่องมันง่ายมากหากทิ้งเรื่อง NF1-NF3 ให้หมด แล้วท่องเอาไว้ในใจว่า"อะไรของอะไรให้มันอยู่ด้วยกัน"... เพียงแค่นี้ก็จะได้ Entity ไล่เรียงเป็นรายการยาว และกลายเป็นคอนเซ็ปต์ของ OOP ไปเสียเลยในคราวเดียวกันนั่นแหละ แล้วจากนั้นก็ลาก Key Field เอาจากด้านหัวไปแปะไว้ในตารางด้านหาง(จาก 1 ไปแปะที่ Many) ซึ่งไม่น่าเชื่อว่าแค่ประโยค 2 ประโยคที่ว่านี่สามารถ"ลากยาว"เป็นหนึ่งวิชา 3 หน่วยกิตในมหาลัยมาตรฐานฯ... ไม่ฮา...

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

เรื่องที่ 2 คือข้อจำกัดของฮาร์ดแวร์สมัยก่อน ที่มีเม็มโมรี่จำกัด และมี CPU ทำงานช้า, ตัวอย่างเช่นอยากรู้ว่าผู้ป่วยในระบบฐานข้อมูลจำนวน 1 แสนคนมีใครเป็นโรคหวัดนกบ้าง ซึ่งเราไปค้นข้อมูลอย่างนี้ใน RDBMS นั่นก็แปลว่าเครื่องคอมฯ จะต้องโหลดตาราง"ผู้ป่วย"ทั้งแสนคนมาในเม็ม(หรือตารางข้อมูลชั่วคราว) แล้วโหลดตาราง"โรค"ทั้งหมดเข้ามาด้วย จากนั้นก็ไล่เช็ค Key field ว่าของใครมันตรงกัน แล้วก็ดีดเรคคอร์ด Output ไปใส่ในอีกตารางชั่วคราวไว้แสดงผลลัพธ์... แต่ตรงกันข้ามหากจัดเก็บข้อมูลไว้ในรูปแบบ Hierarchical databases เครื่องคอมมันจะกวาดหา"แฟลก"โรคหวัดนกจากตาราง"ผู้ป่วย"แค่ตารางเดียว แล้วได้ผลลัพธ์ตูมเดียวเลย(ฐานข้อมูล Hierarchical databases จะยอมเก็บข้อมูลซ้ำกันได้)...

สรุปคือ Hierarchical databases มันทำงานเร็วกว่าในสมัยก่อนครับ... แต่เดี๋ยวนี้ฮาร์ดแวร์ไปไกลแล้ว และที่เขายังคงใช้งาน Hierarchical databases อยู่ ก็เพราะองค์ความรู้มันยังมีอยู่ในสายอาชีพเช่นว่านั้น และมันยังไม่ตัน เขาก็ยังใช้งานต่อไป...

แต่จะว่าไปแล้วคุณป๊อกแมนฯ นี่มหัศจรรย์กว่าครับ เพราะ"สร้างระบบฐานข้อมูล"ด้วยมือตนเองเสียเลย... เพราะจากเท่าที่ให้ข้อมูลมายังใช้ DBF อยู่, นั่นแปลว่าหากจะหาผลลัพธ์ที่เกิดความสัมพันธ์ระหว่างหลายไฟล์ DBF ก็ต้องเปิดอะเรย์ แล้วโหลดทั้งตารางมาเขียนลูปให้เลื่อนทีละเร็คคอร์ดเพื่อวนหาคีย์ฟิลด์... ซึ่งตรงนี้บอกตรงๆ ว่านายสมชายตายแหงๆ หากโดนให้บังคับเขียนโปรแกรมแบบนี้... แฮ่ๆ...

สุดยอดครับ สรุปconcept รวบยอดได้ในไม่กี่ย่อหน้า นับถือเลย ชั่วโมงบินไม่ถึงทำไม่ได้ อย่างตอนที่เคยเล่าให้ฟังว่า มี mail จาก ผบห.ฝ่าย ธ.แห่งนึงขอให้ทำsqlในการ queryให้ ฟังดูอาจจะแปลกๆ แค่sql queryทำไมบุคคลากรของ ธ. ทำเองไม่ได้ จริงๆแล้วผมเล่าแค่ย่อๆ การqueryบน DB ใหญ่ๆที่มีเงื่อนไขแปลกไปจากปกติมันมีfactorที่ต้องคำนึงเยอะ แค่tableเงินฟากตัวเดียวก็เกิน10ล้านrecordแล้ว การqueryก็เลยเหมือนการเขียนโปรแกรม/function ย่อมๆขึ้นมาตัวนึง เพราะต้องคำนึงถึง perfomance และ factor อื่นๆว่าจะไม่ไปกระทบกับงานของ ธ.ด้วย เช่นตอน

แต่ขอแย้งนิดนึง เรื่องที่บอกว่า Hierarchical databases ทำงานได้ช้า ผมว่ามันเหมาะกับงานแต่ละงานมากกว่า เช่นงานที่มีDBใหญ่่ๆ table ทับซ้อน และมีover headเชิงbussinessในการแตะdatabaseเยอะๆ อย่างในงาน ธนาคาร ผมว่ามันสุดยอด(ไม่งั้นที่ บ.คงไม่implementให้ มา4 ธ.ละเนอะ) อย่างDB ดังๆ อย่าง oracle ผมเคยอ่านpaper เจอว่าระบบcore bankที่ implement บน MUMPS ทำงานได้เร็วกว่าถึง8เท่า ซึ่งในการทำงานจริง ผมลัพธ์ก็เป็นแบบนั้นจริงๆ เอาแค่งานง่ายๆ อย่าง extract ข้อมูลบน MUMPSไปแล้วให้ systemอื่นloadหรือกลับทางกัน จะพบว่าelapse time ต่างกันลิบโลก 

แต่จริงๆผมก็ไม่ได้พิศมัยกับมันมากนักหลอก จะหา tools ,lib อะไรมาเบาแรง ไม่ต้่องไปหาเลย ไม่มีหลอก มีปัญหาอะไรขึ้นมา ต้องคิดเอง แก้เอง ต้องไปค้นตำราสมัย ป.ตรี มาreview

55555 พี่  T5  เนี่ยะ  ทำงานอยู่  " ยักษ์ สีฟ้า " หรือเปล่า อ่ะ ฮา 55555 

ยายยังไม่เชื่อน๊า  ว่าเข้าถึงระบบ  หรือแก้ไขระบบ  ได้   อ่ะ ฮา 

ทดลองวิชากันดูหน่อยมั๊ย  อ่ะ ฮา   

5555   โอนเงินเข้าบัญชียายสัก  " ห้าสิบ ล้านเหรียญ " อ่ะ ฮา 5555 

[TakeFive]

นายสมชายลองไปหา database MUMPS เล่นดูครับ ไม่support SQL ครับ ฮาฮา

เพิ่งรู้จักระบบฐานข้อมูลที่ว่าเนี่ยแหละครับ เลยค้นได้ข้อมูลตามลิ้งก์นี้ที่พอสรุปได้เร็วที่สุด... http://healthcaresecurity.wordpress.com/2010/10/12/why-are-hierarchical-databases-like-mumps-still-popular-in-healthcare/ ...

ประเด็นคือ MUMPS เป็นระบบฐานข้อมูลแบบ Hierarchical databases ในขณะที่ SQL เป็นแบบ Relational database management system : RDBMS ... เลยถึงบางอ้อ...

สรุปความได้ว่าที่มันนิยมในโรงบาลฯ กับในสถาบันการเงินมาตั้งแต่สมัย 20 กว่าปีที่แล้วก็เพราะ RDBMS เจอปัญหา 2 อย่างที่คนสมัยโน้นแก้ไม่ตกก็คือ 1) เรื่องความเข้าใจการออกแบบตรรกะข้างใน RDBMS ขยายความได้ว่าเป็นเรื่องของการเขียนสคีม่า(Schema  - Logical design) หรืออธิบายให้นักคอมพิวเตอร์เข้าใจง่ายๆ ก็คือการนอมอลไลเซชั่น(Normalization) ได้แก่การออกแบบตารางและความสัมพันธ์ระหว่างตารางข้อมูลข้างในระบบฐานข้อมูล...

เรื่องข้อที่ 1 นี่เป็นปัญหาจริงๆ แม้แต่ปัจจุบันนี้ก็มีปัญหาว่าออกแบบกันไม่ได้ง่ายๆ แต่ที่จริงแล้วเรื่องมันง่ายมากหากทิ้งเรื่อง NF1-NF3 ให้หมด แล้วท่องเอาไว้ในใจว่า"อะไรของอะไรให้มันอยู่ด้วยกัน"... เพียงแค่นี้ก็จะได้ Entity ไล่เรียงเป็นรายการยาว และกลายเป็นคอนเซ็ปต์ของ OOP ไปเสียเลยในคราวเดียวกันนั่นแหละ แล้วจากนั้นก็ลาก Key Field เอาจากด้านหัวไปแปะไว้ในตารางด้านหาง(จาก 1 ไปแปะที่ Many) ซึ่งไม่น่าเชื่อว่าแค่ประโยค 2 ประโยคที่ว่านี่สามารถ"ลากยาว"เป็นหนึ่งวิชา 3 หน่วยกิตในมหาลัยมาตรฐานฯ... ไม่ฮา...

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

เรื่องที่ 2 คือข้อจำกัดของฮาร์ดแวร์สมัยก่อน ที่มีเม็มโมรี่จำกัด และมี CPU ทำงานช้า, ตัวอย่างเช่นอยากรู้ว่าผู้ป่วยในระบบฐานข้อมูลจำนวน 1 แสนคนมีใครเป็นโรคหวัดนกบ้าง ซึ่งเราไปค้นข้อมูลอย่างนี้ใน RDBMS นั่นก็แปลว่าเครื่องคอมฯ จะต้องโหลดตาราง"ผู้ป่วย"ทั้งแสนคนมาในเม็ม(หรือตารางข้อมูลชั่วคราว) แล้วโหลดตาราง"โรค"ทั้งหมดเข้ามาด้วย จากนั้นก็ไล่เช็ค Key field ว่าของใครมันตรงกัน แล้วก็ดีดเรคคอร์ด Output ไปใส่ในอีกตารางชั่วคราวไว้แสดงผลลัพธ์... แต่ตรงกันข้ามหากจัดเก็บข้อมูลไว้ในรูปแบบ Hierarchical databases เครื่องคอมมันจะกวาดหา"แฟลก"โรคหวัดนกจากตาราง"ผู้ป่วย"แค่ตารางเดียว แล้วได้ผลลัพธ์ตูมเดียวเลย(ฐานข้อมูล Hierarchical databases จะยอมเก็บข้อมูลซ้ำกันได้)...

สรุปคือ Hierarchical databases มันทำงานเร็วกว่าในสมัยก่อนครับ... แต่เดี๋ยวนี้ฮาร์ดแวร์ไปไกลแล้ว และที่เขายังคงใช้งาน Hierarchical databases อยู่ ก็เพราะองค์ความรู้มันยังมีอยู่ในสายอาชีพเช่นว่านั้น และมันยังไม่ตัน เขาก็ยังใช้งานต่อไป...

แต่จะว่าไปแล้วคุณป๊อกแมนฯ นี่มหัศจรรย์กว่าครับ เพราะ"สร้างระบบฐานข้อมูล"ด้วยมือตนเองเสียเลย... เพราะจากเท่าที่ให้ข้อมูลมายังใช้ DBF อยู่, นั่นแปลว่าหากจะหาผลลัพธ์ที่เกิดความสัมพันธ์ระหว่างหลายไฟล์ DBF ก็ต้องเปิดอะเรย์ แล้วโหลดทั้งตารางมาเขียนลูปให้เลื่อนทีละเร็คคอร์ดเพื่อวนหาคีย์ฟิลด์... ซึ่งตรงนี้บอกตรงๆ ว่านายสมชายตายแหงๆ หากโดนให้บังคับเขียนโปรแกรมแบบนี้... แฮ่ๆ...

สุดยอดครับ สรุปconcept รวบยอดได้ในไม่กี่ย่อหน้า นับถือเลย ชั่วโมงบินไม่ถึงทำไม่ได้ อย่างตอนที่เคยเล่าให้ฟังว่า มี mail จาก ผบห.ฝ่าย ธ.แห่งนึงขอให้ทำsqlในการ queryให้ ฟังดูอาจจะแปลกๆ แค่sql queryทำไมบุคคลากรของ ธ. ทำเองไม่ได้ จริงๆแล้วผมเล่าแค่ย่อๆ การqueryบน DB ใหญ่ๆที่มีเงื่อนไขแปลกไปจากปกติมันมีfactorที่ต้องคำนึงเยอะ แค่tableเงินฟากตัวเดียวก็เกิน10ล้านrecordแล้ว การqueryก็เลยเหมือนการเขียนโปรแกรม/function ย่อมๆขึ้นมาตัวนึง เพราะต้องคำนึงถึง perfomance และ factor อื่นๆว่าจะไม่ไปกระทบกับงานของ ธ.ด้วย เช่นตอน

แต่ขอแย้งนิดนึง เรื่องที่บอกว่า Hierarchical databases ทำงานได้ช้า ผมว่ามันเหมาะกับงานแต่ละงานมากกว่า เช่นงานที่มีDBใหญ่่ๆ table ทับซ้อน และมีover headเชิงbussinessในการแตะdatabaseเยอะๆ อย่างในงาน ธนาคาร ผมว่ามันสุดยอด(ไม่งั้นที่ บ.คงไม่implementให้ มา4 ธ.ละเนอะ) อย่างDB ดังๆ อย่าง oracle ผมเคยอ่านpaper เจอว่าระบบcore bankที่ implement บน MUMPS ทำงานได้เร็วกว่าถึง8เท่า ซึ่งในการทำงานจริง ผมลัพธ์ก็เป็นแบบนั้นจริงๆ เอาแค่งานง่ายๆ อย่าง extract ข้อมูลบน MUMPSไปแล้วให้ systemอื่นloadหรือกลับทางกัน จะพบว่าelapse time ต่างกันลิบโลก 

แต่จริงๆผมก็ไม่ได้พิศมัยกับมันมากนักหลอก จะหา tools ,lib อะไรมาเบาแรง ไม่ต้่องไปหาเลย ไม่มีหลอก มีปัญหาอะไรขึ้นมา ต้องคิดเอง แก้เอง ต้องไปค้นตำราสมัย ป.ตรี มาreview

55555 พี่  T5  เนี่ยะ  ทำงานอยู่  " ยักษ์ สีฟ้า " หรือเปล่า อ่ะ ฮา 55555 

ยายยังไม่เชื่อน๊า  ว่าเข้าถึงระบบ  หรือแก้ไขระบบ  ได้   อ่ะ ฮา 

ทดลองวิชากันดูหน่อยมั๊ย  อ่ะ ฮา   

5555   โอนเงินเข้าบัญชียายสัก  " ห้าสิบ ล้านเหรียญ " อ่ะ ฮา 5555 

ไม่ใช่ครับ ยักษ์สีฟ้านี่ตัวปํญหาเลย ลองไปแซะๆฝ่ายitของธ.แถวสะพานแขวนดูสิ
เรื่องเข้าถึงระบบ(production)อยู่ดีๆจะเข้า ตัวผมเข้าไม่ได้อยู่แล้ว ต่อให้ไปนั่งหน้า terminal ที่"ห้องเย็น" ก็ทำอะไรไม่ได้อยู่ดีไม่มีpasswordครับ ถึงมี password ก็ทำการโอนเงินไม่ได้อยู่ดีต้องsetตัวเกือบร้อยตัว ให้สอดคล้องกัน ก่อนจะเรียกคำสั่งโอนได้ ยกตัวอย่างธุรกรรมที่เราทำๆกัน โอนจาก บัญชี A ไป B เงินมันไม่ได้หายจาก A ไปแปะที่ B  แต่มันจะผ่านบัญชีกลางของ ธ. ที่เค้าชอบเรียกๆกันว่า บัญชี GL นั่นแหละ ซึ่งก็มีหลาย hop หลายบัญชี validateกันไม่รู้กี่อย่าง เหนือวิสัยของมนุษย์ที่จะทำได้ครับ

[เบิ้ม]

อ่านแล้วมึน...........ตาลาย เบียร์2-3ขวดละ

ฝากให้คนทำไปคิดไรง่ายๆ  เอากล้องเทวดา...ไรก็ได้ (เสียบปลั๊กได้ยิ่งดี) อยากแปะกล้องตรงไหนก็ติดเลย ติดกาวสองหน้าแบบเทพๆ ไม่หลุด

กี่ตัวก็ว่าไป แล้วส่งภาพมาให้ฮาร์ดดิส ที่ต่อเน็ต จบครับ 

เคยดูข่าว ขโมยขึ้นบ้าน เยอะแยะเลย หัวขโมยมันเคยทำงานติดกล้องวงจรปิด มันเลยรู้วิธี เข้าไปขโมยของ เอาฮาร์ดดิสไปด้วย จบเลย !

เจ้าของบ้าน เจ้าของตึก 

[naisomchai]

อ่านแล้วมึน...........ตาลาย เบียร์2-3ขวดละ

ฝากให้คนทำไปคิดไรง่ายๆ  เอากล้องเทวดา...ไรก็ได้ (เสียบปลั๊กได้ยิ่งดี) อยากแปะกล้องตรงไหนก็ติดเลย ติดกาวสองหน้าแบบเทพๆ ไม่หลุด

กี่ตัวก็ว่าไป แล้วส่งภาพมาให้ฮาร์ดดิส ที่ต่อเน็ต จบครับ 

เคยดูข่าว ขโมยขึ้นบ้าน เยอะแยะเลย หัวขโมยมันเคยทำงานติดกล้องวงจรปิด มันเลยรู้วิธี เข้าไปขโมยของ เอาฮาร์ดดิสไปด้วย จบเลย !

เจ้าของบ้าน เจ้าของตึก 

มันก็มีรุ่นที่ใส่ซิมฯ แล้วยิงรูปทาง 3G เก็บไว้ใน E-mail ไงครับ...

[naisomchai]

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

[naisomchai]

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

[เบิ้ม]

โห............โหดครับพี่สมชาย ดักเสือเลย 

[naisomchai]

โห............โหดครับพี่สมชาย ดักเสือเลย 

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