พื้นหลัง

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

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

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

เราอาจเริ่มมีลูกค้าต่างประเทศเร็ว ๆ นี้ดังนั้นฉันต้องการให้ฐานข้อมูลไม่เกิดการระเบิดหาก / เมื่อเกิดขึ้น ขณะนี้เรายังมี บริษัท ใหญ่สองสามแห่งที่เป็นลูกค้าด้วยแผนกที่แตกต่างกัน (เช่น บริษัท แม่ ACME, แผนกดูแลสุขภาพ ACME, แผนกดูแลร่างกาย ACME)

สคีมาที่ฉันเกิดขึ้นมีดังต่อไปนี้:

1. จากมุมมองของลูกค้า:
   • ลูกค้าคือตารางหลัก
   • ลูกค้าเชื่อมโยงกับแผนกที่พวกเขาทำงาน
     • แผนกสามารถกระจายไปทั่วประเทศ: ฝ่ายทรัพยากรบุคคลในลอนดอนการตลาดในสวอนซี ฯลฯ
     • แผนกมีการเชื่อมโยงกับแผนกของ บริษัท
   • หน่วยงานเชื่อมโยงกับ บริษัท แม่
2. จากมุมมองของชั้นเรียน:
   • เซสชั่นเป็นตารางหลัก
     • ครูจะเชื่อมโยงกับแต่ละเซสชั่น
     • แต่ละสถานะจะได้รับสถานะ เช่น 0 - เสร็จสมบูรณ์ 1 - ถูกยกเลิก
     • เซสชั่นจะถูกจัดกลุ่มเป็น "แพ็ค" ที่มีขนาดตามอำเภอใจ
   • แต่ละชุดถูกกำหนดให้กับลูกค้า

ฉัน "ออกแบบ" (เหมือนเขียนหวัด) สคีมาบนกระดาษพยายามทำให้มันเป็นมาตรฐานในรูปแบบที่ 3 จากนั้นฉันก็เสียบเข้ากับ MySQL Workbench และทำให้มันสวยสำหรับฉัน:
( คลิกที่นี่สำหรับกราฟิกขนาดเต็ม )

_{(ที่มา: maian.org )}

แบบสอบถามตัวอย่างฉันจะทำงาน

• ลูกค้ารายใดที่ยังมีเครดิตเหลืออยู่จะไม่ทำงาน (ลูกค้าที่ไม่มีคลาสที่กำหนดไว้ในอนาคต)
• อัตราการเข้างานต่อลูกค้า / แผนก / แผนก (วัดจากรหัสสถานะในแต่ละเซสชัน) คืออะไร
• มีกี่ชั้นเรียนในหนึ่งเดือน
• ตั้งค่าสถานะลูกค้าที่มีอัตราการเข้างานต่ำ
• รายงานที่กำหนดเองสำหรับแผนกทรัพยากรบุคคลที่มีอัตราการเข้าร่วมของผู้คนในแผนกของตน

คำถาม (s)

• นี่เป็นสิ่งที่ overengineered หรือฉันมุ่งหน้าไปทางที่ถูก?
• ความต้องการในการเข้าร่วมหลายตารางสำหรับการค้นหาส่วนใหญ่จะส่งผลให้เกิดการทำงานที่ยอดเยี่ยมหรือไม่
• ฉันได้เพิ่มคอลัมน์ 'lastsession' ให้กับลูกค้าเนื่องจากอาจเป็นข้อความค้นหาทั่วไป นี่เป็นความคิดที่ดีหรือฉันควรทำให้ฐานข้อมูลเป็นมาตรฐานอย่างเคร่งครัดหรือไม่

ขอบคุณที่สละเวลา

คำตอบสำหรับคำถามของคุณเพิ่มเติม:

1) เป้าหมายของคุณสำหรับคนที่เข้าใกล้ปัญหาเช่นนี้เป็นครั้งแรก ฉันคิดว่าพอยน์เตอร์จากคนอื่นในคำถามนี้จนถึงตอนนี้ เยี่ยมมาก!

2 & 3) ประสิทธิภาพที่คุณจะได้รับส่วนใหญ่จะขึ้นอยู่กับการมีและการปรับดัชนีที่เหมาะสมสำหรับการสืบค้น / ขั้นตอนเฉพาะของคุณและที่สำคัญกว่านั้นคือปริมาณของบันทึก เว้นแต่ว่าคุณกำลังพูดถึงมากกว่าล้านระเบียนในตารางหลักของคุณคุณดูเหมือนจะมีการออกแบบที่สำคัญเพียงพอที่ประสิทธิภาพจะไม่เป็นปัญหาเกี่ยวกับฮาร์ดแวร์ที่เหมาะสม

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

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

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

คุณมีความคิดที่ถูกต้อง อย่างไรก็ตามคุณสามารถล้างข้อมูลและลบตารางการแมป (มี *) บางส่วนได้

สิ่งที่คุณสามารถทำได้คือในตารางแผนกเพิ่ม CityId และ DivisionId

นอกจากนั้นฉันคิดว่าทุกอย่างเรียบร้อยดี ...

การเปลี่ยนแปลงเพียงอย่างเดียวที่ฉันจะทำคือ:
1- เปลี่ยน VARCHAR ของคุณเป็น NVARCHAR หากคุณกำลังจะไปต่างประเทศคุณอาจต้องการยูนิโค้ด

2- เปลี่ยนรหัสประจำตัวของคุณเป็น GUID (Uniqueidentifier) ​​ถ้าเป็นไปได้ (นี่อาจเป็นความชอบส่วนตัวของฉัน) สมมติว่าในที่สุดคุณก็มาถึงจุดที่คุณมีหลาย ๆ สภาพแวดล้อม (dev / test / staging / prod) คุณอาจต้องการย้ายข้อมูลจากที่หนึ่งไปยังอีกที่หนึ่ง มีรหัส GUID ทำให้สิ่งนี้ง่ายขึ้นอย่างมาก

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

4- คุณมีสถานะในตารางลูกค้าที่เป็น VARCHAR และไม่มีลิงค์ไปยังตารางสถานะ ฉันคาดหวังว่าจะมีความชัดเจนมากขึ้นเล็กน้อยเกี่ยวกับสถานะของลูกค้า

ไม่ดูเหมือนว่าคุณกำลังออกแบบรายละเอียดในระดับดี

ฉันคิดว่าประเทศและ บริษัท ต่างเป็นนิติบุคคลเดียวกันในการออกแบบของคุณเช่นเดียวกับเมืองและเขตการปกครอง ฉันจะกำจัดตารางประเทศและเมือง (และ Cities_Has_Departments) และหากจำเป็นให้เพิ่มธงบูลีน IsPublicSector ไปยังตาราง บริษัท (หรือคอลัมน์ CompanyType หากมีตัวเลือกมากกว่าแค่ภาคเอกชน / สาธารณะ)

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

กล่าวอีกนัยหนึ่งลูกค้าควรเชื่อมโยงกับตารางที่คุณเรียก Divisions_Has_Departments (แต่ฉันจะเรียกเพียงแผนก) หากเป็นเช่นนั้นคุณจะต้องยุบเมืองเป็นส่วนต่างๆตามที่กล่าวไว้ข้างต้นหากคุณต้องการใช้การอ้างอิงแบบมาตรฐานในฐานข้อมูล

โดยวิธีการที่มันเป็นที่น่าสังเกตว่าถ้าคุณกำลังสร้าง CSV แล้วและต้องการที่จะโหลดลงในฐานข้อมูล mySQL โหลดข้อมูลท้องถิ่น LOCAL INFILE เป็นเพื่อนที่ดีที่สุดของคุณ: http://dev.mysql.com/doc/refman/5.1/ en Mysqlimport ก็คุ้มค่าที่จะมองหาและเป็นเครื่องมือบรรทัดคำสั่งที่เป็นตัวห่อหุ้มที่ดีรอบ ๆ infile โหลดข้อมูล

สิ่งต่าง ๆ ส่วนใหญ่ได้รับการกล่าวถึงแล้ว แต่ฉันรู้สึกว่าฉันสามารถเพิ่มสิ่งหนึ่งได้: เป็นเรื่องปกติสำหรับนักพัฒนาที่อายุน้อยที่ต้องกังวลเกี่ยวกับประสิทธิภาพเล็กน้อยล่วงหน้ามากเกินไปและคำถามของคุณเกี่ยวกับการเข้าร่วมตารางดูเหมือนจะเป็นไปในทิศทางนั้น นี่คือรูปแบบการต่อต้านการพัฒนาซอฟต์แวร์ที่เรียกว่า 'การเพิ่มประสิทธิภาพก่อนกำหนด ' พยายามขับไล่ภาพสะท้อนนั้นออกจากความคิดของคุณ :)

อีกอย่างหนึ่ง: คุณเชื่อหรือไม่ว่าคุณต้องการตาราง 'เมือง' และ 'ประเทศ' จริงๆ จะไม่มีคอลัมน์ 'เมือง' และ 'ประเทศ' ในตารางแผนกเพียงพอสำหรับกรณีการใช้งานของคุณหรือไม่ ใบสมัครของคุณต้องการรายชื่อแผนกตามเมืองและเมืองตามประเทศหรือไม่?

ความคิดเห็นต่อไปนี้ขึ้นอยู่กับบทบาทในฐานะผู้เชี่ยวชาญด้านระบบธุรกิจ / การรายงานและผู้จัดการกลยุทธ์ / การวางแผน:

1. ฉันเห็นด้วยกับทิศทางของ Larry ด้านบน IMHO มันไม่ได้ถูกออกแบบมามากนักบางสิ่งก็ดูแปลก ๆ เพื่อให้ง่ายฉันจะแท็กไคลเอนต์โดยตรงกับรหัส บริษัท คำอธิบายแผนกคำอธิบายการแบ่งประเภท ID แผนกประเภท ID หมวด ใช้ ID ประเภทแผนกและรหัสประเภทแผนกเป็นข้อมูลอ้างอิงไปยังตารางการค้นหาและฟิลด์การรายงาน / การวิเคราะห์ภายในเพื่อความสอดคล้องในระยะยาว

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

3. ข้อมูล บริษัท สามารถใช้ฟิลด์ได้มากมายรวมถึงที่อยู่ / โทรศัพท์ / ฯลฯ ที่ชัดเจน ข้อมูล. ฉันก็พร้อมที่จะเพิ่มคอลัมน์ DUNs (ไซต์ / สาขา / Ultimate) ในระยะยาว D&B และ Dun and Bradstreet (D&B) มีแคตตาล็อกของ บริษัท จำนวนมากและคุณจะพบภายหลังบนถนนข้อมูลของพวกเขามีประโยชน์มาก สำหรับการรายงาน / การวิเคราะห์ สิ่งนี้จะช่วยจัดการปัญหาการแบ่งส่วนที่คุณพูดถึงและช่วยให้คุณสามารถสรุปลำดับชั้นของพวกเขาสำหรับการย่อย / การแบ่งสาขา / ฯลฯ ของกองใหญ่

4. คุณไม่ได้กล่าวถึงจำนวนระเบียนที่คุณจะใช้ด้วยซึ่งอาจบ่งบอกถึงตัวคุณเองสำหรับการริเริ่มการพัฒนาขนาดใหญ่ซึ่งสามารถทำได้รวดเร็วและปวดหัวน้อยลงด้วยซอฟต์แวร์ "การรายงาน" แบบแพคเกจ หากคุณไม่ได้จัดการกับแถวฐานข้อมูลขนาดใหญ่ (<65000) แถวตรวจสอบให้แน่ใจว่า MS-Access, OpenOffice (ฐาน) หรือโซลูชันรายงาน / แอป dev ที่เกี่ยวข้องไม่สามารถทำเคล็ดลับได้ ฉันใช้ซอฟต์แวร์ APEX ของ Oracle ฟรีมาสักหน่อยแล้วมันมาพร้อมกับฐานข้อมูลฟรี Oracle XE เพียงแค่ดาวน์โหลดจากเว็บไซต์ของพวกเขา

5. FYI - การรายงานข้อมูลเชิงลึก: สำหรับฐานข้อมูลขนาดใหญ่โดยทั่วไปคุณจะมีอินสแตนซ์ฐานข้อมูลสองตัว a) ฐานข้อมูลธุรกรรมสำหรับบันทึกแต่ละรายละเอียด b) ฐานข้อมูลการรายงาน (data mart / data warehouse) ตั้งอยู่ในเครื่องที่แยกต่างหาก สำหรับข้อมูลเพิ่มเติมค้นหาใน Google ทั้ง Star Schema และ Snowflake Schema

ความนับถือ.

ฉันต้องการกล่าวถึงเฉพาะข้อกังวลที่การเข้าร่วมตาราง mutiple จะทำให้การทำงานมีประสิทธิภาพ อย่ากลัวที่จะทำให้ปกติเพราะคุณจะต้องเข้าร่วม การเข้าร่วมเป็นเรื่องปกติและคาดว่าจะเป็นฐานข้อมูลเชิงสัมพันธ์และถูกออกแบบมาเพื่อจัดการได้ดี คุณจะต้องตั้งค่าความสัมพันธ์แบบ PK / FK (สำหรับความถูกต้องของข้อมูลนี่เป็นสิ่งสำคัญที่จะต้องพิจารณาในการออกแบบ) แต่ในฐานข้อมูลจำนวนมาก FKs ไม่ได้จัดทำดัชนีโดยอัตโนมัติ เนื่องจากสิ่งเหล่านี้จะถูกใช้ในการรวมคุณจะต้องเริ่มจากการจัดทำดัชนี FKS PKs โดยทั่วไปได้รับดัชนีการสร้างเนื่องจากพวกเขาจะต้องไม่ซ้ำกัน เป็นความจริงที่การออกแบบคลังเก็บข้อมูลจะลดจำนวนการเข้าร่วม แต่โดยปกติแล้วจะไม่มีการเข้าถึงคลังข้อมูลจนกว่าจะมีระเบียนจำนวนหลายล้านรายการที่ต้องเข้าถึงในรายงานเดียว แม้แต่คลังสินค้าข้อมูลเกือบทั้งหมดก็เริ่มต้นด้วยฐานข้อมูลธุรกรรมเพื่อรวบรวมข้อมูลแบบเรียลไทม์จากนั้นข้อมูลจะถูกย้ายไปยังคลังสินค้าตามกำหนดเวลา (ทุกคืนหรือทุกเดือนหรือทุก ๆ ธุรกิจที่ต้องการ) ดังนั้นนี่เป็นการเริ่มต้นที่ดีแม้ว่าคุณจะต้องออกแบบคลังข้อมูลในภายหลังเพื่อปรับปรุงประสิทธิภาพรายงาน

ฉันต้องบอกว่าการออกแบบของคุณน่าประทับใจสำหรับนักเรียน CS ปีแรก

มันไม่ได้ออกแบบมาให้มากเกินไปนี่คือวิธีที่ฉันจะแก้ไขปัญหา การเข้าร่วมเป็นเรื่องปกติจะไม่มีผลกระทบด้านประสิทธิภาพมากนัก (จำเป็นอย่างยิ่งหากคุณไม่ทำให้ฐานข้อมูลที่ไม่แนะนำ!) สำหรับสถานะดูว่าคุณสามารถใช้ประเภทข้อมูล enum แทนเพื่อเพิ่มประสิทธิภาพของตารางนั้น

ฉันทำงานในโดเมนการฝึกอบรม / โรงเรียนและฉันคิดว่าฉันชี้ให้เห็นว่าโดยทั่วไปแล้วจะมีความสัมพันธ์ M: 1 ระหว่างสิ่งที่คุณเรียกว่า "เซสชัน" (กรณีของหลักสูตรที่กำหนด) และหลักสูตรนั้น กล่าวอีกนัยหนึ่งแคตตาล็อกของคุณมีหลักสูตร ("สเปน 101" หรืออะไรก็ตาม) แต่คุณอาจมีสองกรณีที่แตกต่างกันระหว่างภาคการศึกษาเดียว (Tu-Th สอนโดย Smith, Wed-Fri สอนโดย Jones)

นอกเหนือจากนั้นดูเหมือนว่าจะเป็นการเริ่มต้นที่ดี ฉันพนันได้เลยว่าคุณจะพบว่าโดเมนลูกค้า (กราฟที่นำไปสู่ ​​"ลูกค้า") นั้นซับซ้อนกว่าแบบจำลองของคุณ แต่อย่าไปลงน้ำจนกว่าจะมีข้อมูลจริงที่จะแนะนำคุณ

บางสิ่งที่อยู่ในใจ:

1. ตารางดูเหมือนจะมุ่งไปที่การรายงาน แต่ไม่ได้ดำเนินธุรกิจจริงๆ ฉันจะคิดว่าเมื่อลูกค้าลงทะเบียนมีคำสั่งที่สำคัญสำหรับลูกค้าที่เข้าร่วมรายการของเซสชันและคำสั่งนั้นอาจมีให้กับพนักงานหลายคนใน บริษัท เดียว ดูเหมือนว่าตาราง "คำสั่งซื้อ" จะเป็นศูนย์กลางของระบบของคุณและผลักดันการเก็บข้อมูลและการรายงานในที่สุด (เปรียบเทียบเอกสารที่เป็นกระดาษที่คุณใช้ในการดำเนินธุรกิจกับการออกแบบฐานข้อมูลของคุณเพื่อดูว่ามีข้อมูลตรงกันหรือไม่)

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

3. แนวคิด "แพ็ค" ไม่ชัดเจนเลย

4. เนื่องจากคุณระบุว่าเป็นธุรกิจขนาดเล็กมันจะน่าแปลกใจถ้าประสิทธิภาพจะเป็นปัญหาพิจารณาความเร็วและความจุของเครื่องจักรปัจจุบัน