ปรึกษาปัญหาเรื่องโปรแกรมครับ
ตอนนี้ มีโปรแกรมที่ใช้ในการบันทึกข้อมูล ประมวลผลของลูกค้า
เขียนด้วย Delphi , Database เป็น my SQL
ต้้องการให้ผู้พัฒนา เพิ่ม feature turn around time warning ครับ
โดยระบบ มีการออกแบบไว้ว่า ลูกค้าแต่ละคน ที่มาคอยคิว จะมีระบบประกันเวลาเอาไว้ ว่าจะไม่นานเกินเท่าไร
ความต้องการคือ ให้มีสถานะนเตือนสีเขียว เหลือง แดง สำหรับสีเขียว ก็ปกติ ไม่มีปัญหา สีเหลือง คือเหลือเวลาน้อยกว่าสิบนาที สีแดง คือเกินเวลาไปแล้ว
และให้มีหน้าจอ sorting ตามเวลาที่เหลืออยู่ เพื่อให้เจ้าหน้าที่ จัดลำดับการทำงาน ของลูกค้าที่ใกล้จะครบเวลา โดยนำมาทำก่อน
คราวนี้ ปัญหาเมื่อแจ้งความต้องการกับโปรแกรมเมอร์ ได้รับคำตอบว่าทดลองแล้ว ทำให้ server ประมวลผลหนักมาก เพราะเท่ากับต้องสร้าง timer ตามจำนวนลูกค้า*3 เพราะมี 3 หน่วยงาน ซึ่งก็เกือบ 1000 รายการแล้ว ทุกครั้งที่ refresh จะต้องเปรียบเทียบเวลาตลอด ยิ่ง refresh ถี่เท่าไหร่ ก็ยิ่งทำให้งานโดยรวมช้า เพราะตอนนี้ แค่เรียกข้อมูลลูกค้าทีละรายมาเพื่อบันทึกข้อมูล ก็ต้องรอ จากที่เดิมเคยเรียกแล้วมาได้ทันที
ไม่ทราบว่ามีวิธีคิดแบบอื่น ที่ไม่เป็นภาระกับ server หรอไม่ครับ ตรงนี้ เป็น feature ที่สำคัญ ที่จะต้องใช้เพื่อทำงานประกันคุณภาพ และเท่าที่ฟังจาก programmer feature นี้ ใช้ทรัพยากร มากกว่างานอื่นรวมกัน
รบกวนขอแนวคิด การจัดการกับปัญหานี้ด้วยครับ ผมจะได้แจ้งให้โปรแกรมเมอร์ที่พัฒนา software ทราบ เพื่อหาทางแก้ไขปัญหา เพื่อให้ใช้งานได้ครับ
ขอขอบคุณล่วงหน้าครับ
client เชื่อมต่อกับ server
bongikairu Mon, 30/07/2012 - 21:51
client เชื่อมต่อกับ server ที่มีแค่ mySQL ใช่ไหมครับ ? สงสัยว่าทำไมต้องสร้าง timer ตั้งเยอะแยะ ไม่ใช้ตัวเดียวแล้ว loop เอาหละครับ ?
คือลูกค้้าแต่ละคน
specimen Mon, 30/07/2012 - 22:23
คือลูกค้้าแต่ละคน เข้ามาไม่พร้อมกันครับ ต้องจับเวลาแยกลูกค้าแต่ละราย
โปรแกรมเมอร์ เขาอธิบายให้ฟังตามนี้ละครับ
ลักษณะงาน ก็เป็นโปรแกรมลักษณะ client server ครับ การบั้นทึกข้อมูลทำบน client ประมวลผล แสดงผลบางส่วนบน client ครับ ส่งไปเก็บข้อมูล และ update ข้อมูลบน server ครับ
ช่วยอธิบายความหมายของการใช้ตัวเดียวแล้ว loop เอา ด้วยครับ ว่าจะใช้กับลูกค้าแยกแต่ละรายอย่างไรครับ
ขอบคุณครบ
server ทำแค่บันทึกเวลา start
McKay Mon, 30/07/2012 - 22:51
server ทำแค่บันทึกเวลา start time หรือ end time ลง db ก็พอครับ ส่วนพวกนาฬิกา/สถานะเตือน/timer ก็ให้เป็น client side แทน แล้ว sync เวลาขณะ refresh เอา
อาจจะสร้าง table ที่บันทึกคิวลูกค้าขึ้นมาก็ได้ครับ
แนวคิดนี้ ผมเสนอไปแล้วครับ
specimen Tue, 31/07/2012 - 00:41
In reply to server ทำแค่บันทึกเวลา start by McKay
แนวคิดนี้ ผมเสนอไปแล้วครับ เขาบอกว่าทำไม่ได้ แต่ไม่ได้ให้เหตุผลครับ
ลองถามเหตุผลครับ
mr_tawan Tue, 31/07/2012 - 08:26
In reply to แนวคิดนี้ ผมเสนอไปแล้วครับ by specimen
ลองถามเหตุผลครับ ผมว่าวิธีนี้น่าจะทำได้ไม่ยากนะ
client เป็นอะไรครบ web based ?
เดี๋ยวลองถามให้ครับ โปรแกรมไม
specimen Tue, 31/07/2012 - 11:41
In reply to ลองถามเหตุผลครับ by mr_tawan
เดี๋ยวลองถามให้ครับ
โปรแกรมไม่ได้เป็น web base ครับ
คือดูยังไงก็ควรจับเวลาบน
kowito Tue, 31/07/2012 - 14:40
In reply to เดี๋ยวลองถามให้ครับ โปรแกรมไม by specimen
คือดูยังไงก็ควรจับเวลาบน Client ถ้าทำไม่ได้ก็ต้องชี้แจงเหตุผล ตัว Delphi มันทำได้อยู่แล้ว
เดี๋ยวคืนนี้ลองคุยดูครับ
specimen Tue, 31/07/2012 - 18:31
In reply to คือดูยังไงก็ควรจับเวลาบน by kowito
เดี๋ยวคืนนี้ลองคุยดูครับ
อ่านแล้วก็มึนๆงงๆติดสตั๊นนะ แ
SleeperMoNKeY Tue, 31/07/2012 - 00:07
อ่านแล้วก็มึนๆงงๆติดสตั๊นนะ
แต่ตามหลักความคิดของผมก็คือ เมื่อลูกค้าเข้ามาก็ให้บันทึกเวลาที่เข้าลง db ไป จากนั้นเรื่องการจับเวลาให้เป็นเรื่องของ client
โดยอาจใช้การเปรียบเทียบกับเวลาในเครื่อง client แล้วหาส่วนต่างก็ได้ครับ
แนวคิดนี้ช่วยได้ไหมครับ
ผมก็เสนอตามนี้ละครับ
specimen Tue, 31/07/2012 - 00:43
In reply to อ่านแล้วก็มึนๆงงๆติดสตั๊นนะ แ by SleeperMoNKeY
ผมก็เสนอตามนี้ละครับ แต่เค้าก็บอกว่าไม่ได้
ผมเสนอให้ update สถานะคนไข้ เนื่องจากมี client หลายเครื่อง
แล้วจัดการเฉพาะสถานะคนไข้ที่ยังไม่จบกระบวนการครับ
ระบบตรวจสอบเวลาเพื่อรับประกัน
MN Tue, 31/07/2012 - 00:41
ระบบตรวจสอบเวลาเพื่อรับประกันเวลาออกผลตรวจlabใช่ไหม เดาจากชื่อ
การตรวจlabมีหลายชนิด ใช้เวลาต่างกัน แล้วมีการรับประกันเวลา
แล้วlabชนิดที่ใช้เวลาน้อยจะถูกทำให้ช้าจากlabชนิดที่ใช้เวลาทำนานที่อยู่ในคิวก่อนหน้าใช่ไหม
เลยจะมีระบบเตือน
แหะๆ เดาเป็นตุเป็นตะเลย
เดาแม่นครับ แต่วัตถุประสงค์คื
specimen Tue, 31/07/2012 - 00:47
In reply to ระบบตรวจสอบเวลาเพื่อรับประกัน by MN
เดาแม่นครับ
แต่วัตถุประสงค์คือ ในกรณีที่ีมีคนไข้ มาเจาะเลือดไม่พร้อมกัน
แต่มีการ process งานพร้อม ๆ กัน เราจะเลือกทำงานกับคนไข้ ที่เจาะเลือดนานที่สุดก่อนครับ
เพราะการทำ lab ไม่ใช่เพียงแต่เอาผลจากเครื่องมารายงานได้เลยครับ
ต้องมีการทำเพิ่มเติม และตรวจสอบโดยมนุษย์ก่อนครับ ก็เลยจะใช้วิธีนี้ ในการจัดการกับคนไข้ ที่มาก่อนครับ
และระบบนี้ จะใช้ในการจัดการกับคนไข้ด่วนด้วยครับ
ถ้าด่วน ก็จะมีการจัดการใน priority ที่สูงกว่าครับ
งั้นเปลี่ยนนิยามของการรับประก
MN Tue, 31/07/2012 - 00:56
In reply to เดาแม่นครับ แต่วัตถุประสงค์คื by specimen
งั้นเปลี่ยนนิยามของการรับประกันเวลาจะง่ายกว่านะ
อันนี้ไม่ได้ตอบกวนนะ เพราะเคยมีกรณีคล้ายๆอย่างนี้ แล้ววิธีจัดการมันยุ่งมาก
ก็แก้ด้วยการปรับนิยามเล็กน้อย ทำให้แก้ปัญหาไปได้
ไม่งั้นอาจต้องมีเครื่องคอมพ์สำหรับจับเวลาเครื่องหนึ่งแยกต่างหาก
ลักษณะไหนดีครับ ทุกวันนี้
specimen Tue, 31/07/2012 - 01:03
In reply to งั้นเปลี่ยนนิยามของการรับประก by MN
ลักษณะไหนดีครับ
ทุกวันนี้ งานจะเป็นลักษณะว่า ถ้าหน่วยงาน A จะใช้เวลาไม่เกิน 45 นาที หลังเจาะเลือด
หน่วย B ใช้เวลา 50 นาที จะรายงานผลได้
เราจะเปลี่ยนเป็นแบบไหนดีครับ อาจจะเป็นเส้นผมบังภูเขาก็ได้ คือผมอาจจะมองแค่มุมเดียวก็ได้
อีกอย่าง เป้าหมายหลัก คือการจัดคิวงานครับ ว่าจะทำรายไหนก่อน แต่ความซับซ้อนมันอยู่ที่แต่ละรายการ ใช้เวลาไม่เท่ากัน และคนทำ ไม่รู้ว่าคนไข้รายไหนมาก่อน ก็เลยจะใช้ระบบนี้เป็นตัวช่วยครับ เพื่อคุมให้งานออกได้ตามเวลา และคนไข้ที่มาก่อน ได้ผลก่อนด้วย
มีคนไข้มาเจาะเลือดที่หน้าห้อง
MN Tue, 31/07/2012 - 01:23
In reply to ลักษณะไหนดีครับ ทุกวันนี้ by specimen
มีคนไข้มาเจาะเลือดที่หน้าห้องlabหรือห้องเจาะเลือด
มีคนไข้เจาะเลือดจากวอร์ดส่งลงมา
มีคนไข้เจาะเลือดก่อนขึ้นวอร์ด เจาะที่หนึ่งเรียกดูผลอีกที่หนึ่ง
เลือดแยกตรวจไปใน 3 หน่วยงานคือ เซลล์ เคมี อิมมูโน เวลาออกผลไม่เท่ากัน
เดื๋ยวขอคิดให้รอบคอบซักวันหนึ่งก่อน ตอบเร็วไม่ได้ ไว้พรุ่งนี้จะมาคุยอีกครั้ง ขออนุญาตนะครับ
จะรอนะคร้าบบ แต่...คนไข้มาจาก
specimen Tue, 31/07/2012 - 01:36
In reply to มีคนไข้มาเจาะเลือดที่หน้าห้อง by MN
จะรอนะคร้าบบ
แต่...คนไข้มาจากไหนไม่เป็นประเด็นนะครับ turn around time เท่ากันครับ ขึ้นอยู่กับ test ที่ตรวจ และหน่วยงานที่ตรวจมากกว่าครับ
เราไม่สนที่มาครับ เข้ามาใน lab จะถูก process เหมือนกันหมด ยกเว้นมีการขอด่วนมาเท่านั้นครับ
แค่นี้ก็ซับซ้อนตายแล้วครับ
ขอบคุณล่วงหน้าครับ
ขอถามเพิ่มเล็กน้อย 1
MN Tue, 31/07/2012 - 15:37
In reply to จะรอนะคร้าบบ แต่...คนไข้มาจาก by specimen
ขอถามเพิ่มเล็กน้อย
1 เริ่มจับเวลาเมื่อไร เมื่อลงทะเบียนรับspecimenใช่ไหม
2 ตอนแยกspecimen ไปแต่ละหน่วยตรวจลงทะเบียนอย่างไร ต้องลงทะเบียนอีกทีหรือเปล่า หรือให้ส่งspecimenที่หน่วยตรวจนั้นๆเลย
3 ตอนกลางวันสามารถแยกหน่วยตรวจได้ แล้วตอนกลางคืนล่ะ แยกหน่วยแยกคนทำเหมือนกลางวันหรือมีคนอยู่เวร 1-2 คนแล้วเหมาทำหมด แล้วกลางคืนงดส่ง งดทำlabบางชนิดหรือเปล่า
4 การรับประกันเวลาแยกตามหน่วยตรวจ หรือแยกตามชนิด test ถ้าแต่ละtestในหน่วยตรวจเดียวกันประกันเวลาไม่เท่ากัน ก็จะมีการคำนวณคิวและการแทรกคิวอยู่เสมอ เพราะต้องเอาtestที่เวลาเหลือน้อยมาเรียงทำก่อนซึ่งต้องไปคำนวณร่วมกับเวลาที่ใช้ในการทำtestนั้นๆด้วย รับspecimenจากคนไข้มาไล่เรี่ยกัน แต่ต้องมาเรียงทำสลับไปมาตามแต่คิวเวลาเหลือ จะยุ่งยากมาก
5 specimenที่รับมาเอาtubeมาเรียงแบบเป็นคิวหรือเปล่า
ขอถามเพิ่มเล็กน้อย 1
specimen Tue, 31/07/2012 - 18:36
In reply to ขอถามเพิ่มเล็กน้อย 1 by MN
ขอถามเพิ่มเล็กน้อย
1 เริ่มจับเวลาเมื่อไร เมื่อลงทะเบียนรับspecimenใช่ไหม
฿฿฿ใช่ครับ
2 ตอนแยกspecimen ไปแต่ละหน่วยตรวจลงทะเบียนอย่างไร ต้องลงทะเบียนอีกทีหรือเปล่า หรือให้ส่งspecimenที่หน่วยตรวจนั้นๆเลย
฿฿฿ไม่ต้องครับ
3 ตอนกลางวันสามารถแยกหน่วยตรวจได้ แล้วตอนกลางคืนล่ะ แยกหน่วยแยกคนทำเหมือนกลางวันหรือมีคนอยู่เวร 1-2 คนแล้วเหมาทำหมด แล้วกลางคืนงดส่ง งดทำlabบางชนิดหรือเปล่า
฿฿฿เหมาครับ ตรวจได้บางรายการครับ
4 การรับประกันเวลาแยกตามหน่วยตรวจ หรือแยกตามชนิด test ถ้าแต่ละtestในหน่วยตรวจเดียวกันประกันเวลาไม่เท่ากัน ก็จะมีการคำนวณคิวและการแทรกคิวอยู่เสมอ เพราะต้องเอาtestที่เวลาเหลือน้อยมาเรียงทำก่อนซึ่งต้องไปคำนวณร่วมกับเวลาที่ใช้ในการทำtestนั้นๆด้วย รับspecimenจากคนไข้มาไล่เรี่ยกัน แต่ต้องมาเรียงทำสลับไปมาตามแต่คิวเวลาเหลือ จะยุ่งยากมาก
฿฿฿จะคิดจากรายการที่นานที่สุดใน request เสมอครับ
5 specimenที่รับมาเอาtubeมาเรียงแบบเป็นคิวหรือเปล่า
฿฿฿ไม่ครับ
ขอบคุณครับ ที่ใส่ใจในรายละเอียดขนาดนี้ ดูจากการถาม น่าจะเป็นท่านที่ทำงานในสายงานนี้ ดูแล LIS ซักเจ้าแน่เลย ไม่งั้นก็ HIS
ผมเดาครับ
ก่อนอื่นต้องตัดสินใจก่อนว่าจะ
MN Tue, 31/07/2012 - 21:40
In reply to ขอถามเพิ่มเล็กน้อย 1 by specimen
ก่อนอื่นต้องตัดสินใจก่อนว่าจะเลือกแบบไหน ระหว่างรับspecimenก่อนทำให้ก่อน กับคนไหนเวลาเหลือน้อยเอามาทำก่อน เพราะในคำตอบของคุณมีความต้องการปนกัน อย่างหลังคำนวณเยอะ แต่บางทีผลที่ได้อาจไม่ต่างจากมาก่อนทำให้ก่อนเท่าไรนัก อย่างแรกก็มีหน้าจอให้ดูว่าspecimenไหนมาก่อนก็เอาไปทำก่อน ได้ผลlabก็มาapproveแล้วก็ออกผลมีเวลาออกผล แล้วก็ประมวลผลทำงานเป็นสัปดาห์หรือเป็นเดือนว่าส่วนใหญ่ประมาณ 90-95%หรือ 99% ออกผลได้ในเวลาหรือเปล่าถ้าไม่ได้ก็ root-cause analysis ตามด้วยcontinuous improvement ว่ากันไป ปรับปรุงเป็นระบบให้เร็วขึ้น ที่ให้ประกันเวลาไม่ถึง 100% เพราะอาจจะมีผลบางครั้งมันประหลาดต้องเอากลับมาconfirmอีกครั้งก็ทำให้เวลาเสียไป(อันนี้เป็นตัวอย่างการเปลี่ยนนิยาม)
อย่างหลังก็ต้องคำนวณทุกนาทีว่าใคร(คนไข้)หรือspecimenไหนมีเวลาเหลือเท่าไร แล้วเรียงใหม่ ซึ่งคิวก็อาจเหมือนเดิม แต่ต้องเปลืองพลังคำนวณ แล้วเวลากลางคืนระบบนี้ก็ไม่มีความหมายเพราะคนไข้จะฉุกเฉินเกือบหมดทุกคน คนทำlabก็ไม่แยกห้อง ตารางคำนวณเวลาทำlabกลางวันก็เป็นแบบหนึ่งกลางคืนก็เป็นอีกแบบหนึ่ง แล้วเวลากลางวันคนไข้opdได้ผลเร็วเป็นบางอย่างเพราะห้องทำlabชนิดนั้นมีrequestน้อยก็ไม่มีความหมายเพราะหมอต้องรอผลตรวจครบก่อนอยู่ดีถึงจะสั่งยากลับบ้านได้
อันความต้องการทั้งสองข้อเอามารวมกันก็ได้อยู่แต่จะเกิดปรากฎการดังปัญหาที่ถามมา
เลือกวิธีทำง่ายก่อนดีกว่าเนอะ
โอเคครับ มีเหตุผล
specimen Tue, 31/07/2012 - 22:22
In reply to ก่อนอื่นต้องตัดสินใจก่อนว่าจะ by MN
โอเคครับ มีเหตุผล และนำไปใช้ได้ดีเลยครับ
เดี๋ยวจะลองคุยกับคนพัฒนาดูครับ ในแนวคิดนี้ครับ
น่าจะง่ายกว่าครับ
ขอบคุณครับ
ชัดเจน
สรุปรวมหลาย ๆ ท่าน
specimen Tue, 31/07/2012 - 00:55
สรุปรวมหลาย ๆ ท่าน แนะนำให้ทำงานในส่วนของ client แทน
แต่ปัญหาคือ มีหลายหน่วยงาน มี client หลายเครื่อง client แต่ละเครื่อง ไม่ได้ fix ประจำหน่วยงานด้วยครับ
แนวคิดนี้ ทำได้แน่ใช่ไม๊ครับ ตามเงื่อนไขที่ผมแจ้งไปในบรรทัดบน
ผมจะได้เอาไปยันกับ โปรแกรมเมอร์ครับ
ตอนนี้ ความคิดผม ถ้าจะทำงานบน client ก็จะทำงานเฉพาะตอนเปิดหน้าจอนี้
แล้วขึ้นอยู่กับเปิดหน่วยงานไหน ก็ load data มาเฉพาะคนไข้ของหน่วยงานนั้น
แล้ว sync กับ server เฉพาะสถานะของคนไข้ เอารายที่เสร็จแล้วออกไป
ส่วน client ก็ทำงานเฉพาะการเอา start time มาคำนวนเทียบกับเวลาในเครื่อง
ดังนั้น ภาระของ client ก็น่าจะน้อยลง เพราะจะทำงานก็ต่อเมื่อเราเปิดหน้านี้เท่านั้น
ภาระของ server ก็ไม่มี
ผมเข้าใจถูกหรือไม่ครับ รบกวนแนะนำด้วยครับ
ขอ share
fatrabb1t Tue, 31/07/2012 - 01:49
ขอ share ที่คิดนะครับ
ผมมองว่าเรื่องใช้ timer เนี่ย เนื่องจากไม่แน่ใจเรื่องการออกแบบฝั่ง client ว่าส่วนที่้ต้องใช้ timer บน client (ถ้าย้ายมาทำบน client จริงๆ) ต้องใช้ timer เยอะหรือเปล่า เพราะเท่าที่ดูเดาว่าน่าจะเยอะ ซึ่งถ้าเป็นแบบนั้นเครื่อง client ก็ตายเหมือนกัน ซึ่งถ้าเป็นกรณีแบบนี้อาจจะต้องหาวิธีจัดการที่ดีกว่า timer เช่น เรารู้อยู่แล้วว่าแต่ละ case มีเวลาไหนที่จะเปลี่ยน status บ้าง ยกตัวอย่างเช่น start time 10.00 จะต้องเปลี่ยน status เวลา 10.30 ก็ทำเป็น data structure ที่เก็บ time slot ไว้ว่าเวลาไหนมี event ไหนที่ต้องทำบ้าง แล้วให้ทุกๆ object นำข้อมูลเวลาที่ต้องการ trigger มาใส่ในนี้ทั้งหมด แล้วก็ใช้ timer แค่ตัวเดียว check ก็อาจจะช่วยได้
ขอบคุณครับ ในอีกทางเลือก
specimen Tue, 31/07/2012 - 02:18
In reply to ขอ share by fatrabb1t
ขอบคุณครับ ในอีกทางเลือก จะนำทางเลือกนี้ เสนอให้โปรแกรมเมอร์ แล้วจะลองดูว่า feedback เขาจะว่ามายังไงครับ เป็นทางออกที่ีดีอีกทางเลยครับ ไม่ต้องเป็นภาระในการประมวลผลเยอะด้วย