หากตามที่ระบุไว้ในโพสต์ของคุณความตั้งใจคือการสร้างความสัมพันธ์ฐานข้อมูล (RDB สำหรับความกะทัดรัด) และดังนั้นจึงคาดว่ามันจะทำงานเช่นนั้นคำตอบสั้น ๆ คือ:
- ไม่คุณไม่ควรมองข้ามข้อ จำกัด ด้านความสมบูรณ์ของข้อมูลไม่มีคุณไม่ควรมองข้ามข้อ จำกัด ของความสมบูรณ์ของข้อมูล
วัตถุประสงค์หลักควรจัดการข้อมูลที่เกี่ยวข้องเนื่องจากเป็นทรัพย์สินขององค์กรที่มีค่าและวิธีการที่เชื่อถือได้เพื่อให้บรรลุวัตถุประสงค์ดังกล่าวคือใช้วิธีการทางเทคนิคที่สนับสนุนทฤษฎีเสียง
ดังนั้นในฐานะผู้เชี่ยวชาญด้านฐานข้อมูลคุณสามารถใช้ประโยชน์จากโมเดลเชิงสัมพันธ์ที่ทันสมัยและหรูหรากลไกจัดทำโดยDr. EF Coddเพื่อบังคับใช้กฎเกณฑ์ทางธุรกิจและหลีกเลี่ยงปัญหาที่จะเกิดขึ้นในที่สุดหากไม่ได้ใช้ประโยชน์
ในส่วนนี้ฉันจะแบ่งปัน (a) ข้อ จำกัด โดยรวมของฉันและ (ข) ข้อควรพิจารณาหลายประการเกี่ยวกับสถานะของกิจการของฐานข้อมูลและสภาพแวดล้อมการทำงานที่มีปัญหาดังต่อไปนี้
ข้อ จำกัด ที่สำคัญของต่างประเทศความสัมพันธ์ของข้อมูลและความสมบูรณ์ของการอ้างอิง
RDB ต้องสะท้อนให้เห็นถึงลักษณะของบริบททางธุรกิจที่น่าสนใจด้วยความแม่นยำสูงซึ่งต้องมีการวิเคราะห์เชิงลึกในระดับแนวคิดที่นำโดยผู้สร้างแบบจำลองหรือนักออกแบบที่ปฏิบัติตามแนวปฏิบัติที่ดีที่สุดโดยนับรวมกับความช่วยเหลือที่จำเป็นจากผู้เชี่ยวชาญ การวิเคราะห์นั้นจะต้องให้การระบุที่ถูกต้องและการกำหนดกฎเกณฑ์ทางธุรกิจที่เกี่ยวข้อง
ดังนั้นหากผู้สร้างแบบจำลองดังกล่าวได้ระบุว่ามีความสัมพันธ์ระหว่างข้อมูลที่เกี่ยวข้องเขาหรือเธอจะต้องกำหนดค่าข้อ จำกัดระดับตรรกะที่สอดคล้องกันเพื่อให้ระบบการจัดการฐานข้อมูล (DBMS) สามารถรับประกันได้ว่าข้อมูลยังคงสอดคล้องกับลักษณะที่แน่นอนและ กฎที่กำหนดไว้ในการวิเคราะห์ที่อ้างถึงข้างต้นตลอดเวลา
เกี่ยวกับฐานข้อมูลภายใต้การสนทนาเราสามารถอนุมานได้ว่ามีการระบุความสัมพันธ์ที่เกี่ยวข้องกันเนื่องจากคุณพูดถึงว่ามีความพยายามในขั้นตอน (และหลีกเลี่ยงได้ง่าย) ในการบังคับใช้พวกเขาจากภายนอกสิ่งอำนวยความสะดวก DBMS โดยอาศัยรหัสโปรแกรม เป็นวิธีการก่อนความสัมพันธ์) ซึ่งในกรณีใด ๆ จะต้อง "สัมผัส" ฐานข้อมูลเพื่อพยายามตรวจสอบความสมบูรณ์ของความสัมพันธ์ดังกล่าว
อย่างไรก็ตามดังที่คุณทราบนั่นไม่ใช่เทคนิคที่ดีที่สุดในการปกป้องความสมบูรณ์ของการอ้างอิงเนื่องจากวิทยาศาสตร์เชิงสัมพันธ์ได้กำหนดเครื่องมือที่ทรงพลังมากสำหรับจุดประสงค์นี้เช่นข้อ จำกัด ของ FOREIGN KEY (FK) ข้อ จำกัด เหล่านี้ง่ายต่อการสร้าง (ผ่านวิธีการเปิดเผยที่เหนือกว่า) เนื่องจากเป็นแบบเดี่ยวประโยคที่หลีกเลี่ยงการหันไปใช้วิธีเฉพาะกิจแบบไม่จำเป็นและเกิดข้อผิดพลาดได้ง่าย มันมีประโยชน์มากที่จะต้องทราบว่าความเร็วในการดำเนินการของข้อ จำกัด FK ได้รับการปรับให้เหมาะสมอย่างสูงโดยโปรแกรมเมอร์ผู้เชี่ยวชาญ (และผู้จำหน่ายแพลตฟอร์มรายใหญ่ได้ทำงานกับมันมาหลายทศวรรษแล้ว)
นอกจากนี้เนื่องจาก RDB จะต้องเป็นองค์ประกอบซอฟต์แวร์อิสระ (ป้องกันตนเองอธิบายตนเอง ฯลฯ ) ที่สามารถเข้าถึงได้โดยแอปพลิเคชันหลายโปรแกรม (เดสก์ท็อปอัตโนมัติเว็บมือถือรวมกัน) จึงไม่ควร “ ควบคู่” กับรหัสของแอพใด ๆ เหล่านี้
ในทำนองเดียวกันข้อมูล - ซึ่งเป็นทรัพยากรสำคัญขององค์กร - มีแนวโน้มที่จะอยู่เหนือกว่าแอปพลิเคชันโปรแกรมโปรแกรมเมอร์แอปพลิเคชันแพลตฟอร์มการพัฒนาแอปพลิเคชันและกระบวนทัศน์การเขียนโปรแกรม
ข้อ จำกัด คีย์หลักและความหมายของแถวที่ซ้ำกัน
เมื่อ -conceptually speaking- เฉพาะชนิดของสิ่งที่ได้รับถือว่ามีความสำคัญในสภาพแวดล้อมทางธุรกิจที่สร้างแบบจำลองฐานข้อมูลที่มีการ (1) กำหนดลักษณะที่เกี่ยวข้อง -ie, Properties- ตนยืนยันกล่าวว่าชนิดของสิ่งเป็นกรณีนิติบุคคลต้นแบบ - เช่นประเภทเอนทิตี - และ (2) เป็นตัวแทนของมันโดยวิธีการของตารางที่รวมโดยหนึ่งหรือมากกว่าหนึ่งคอลัมน์ในการออกแบบเชิงตรรกะ
จากนั้นเช่นเดียวกับการมีความสำคัญยิ่งที่จะแยกแยะอินสแตนซ์แต่ละประเภทของเอนทิตีที่กำหนดในโลกแห่งความเป็นจริงแต่ละแถวที่อยู่ในตารางจะต้องมีความโดดเด่นไม่เหมือนกัน ถ้าตารางไม่ได้มีปุ่มใด ๆ ประกาศในที่สุดมันก็จะยังคงมีรายการที่ซ้ำกันและถ้ามีสองคนหรือมากกว่าแถวที่เก็บค่าตรงเดียวกันแล้วพวกเขาทั้งหมดดำเนินการเดียวกันความหมายพวกเขาทั้งหมดเป็นตัวแทนเดียวกันความเป็นจริงความเป็นจริง
ในจุดนั้นควรยกเลิกแถวที่ซ้ำกันเนื่องจากสาเหตุหลายประการ จากมุมมองทางทฤษฎีนักออกแบบต้องตรวจสอบให้แน่ใจว่าแต่ละแถวนั้นไม่ซ้ำกันเสมอเพื่อจุดประสงค์ในการมีตารางที่ทำงานอย่างมีความสัมพันธ์เหมือนกับการอนุญาตให้ใช้ภาษาย่อยของข้อมูล SQL นอกจากนี้จากมุมมองที่ให้ข้อมูลหากหลายแถวแสดงถึงความจริงเดียวกันการบันทึกของพวกเขาไม่เพียง แต่ฟุ่มเฟือย แต่เป็นอันตรายเช่นร้องสุดขั้ว:
- สมมติว่ามีบางคนแทรกแถวที่เหมือนกันสองแถวในตารางหนึ่ง
- หลังจากนั้นมีคนอื่นมาและอัปเดตรายการที่ซ้ำกันเพียงครั้งเดียว เป็นผลให้เกิดเหตุการณ์อื่นไม่ทันสมัยอีกต่อไป
- คนอื่นอัปเดตเหตุการณ์ที่ไม่ได้รับการแก้ไขอย่างต่อเนื่อง ในลักษณะนี้สำเนาที่ซ้ำกันทั้งคู่จะผ่านการเปลี่ยนแปลงที่แตกต่างกันตามเวลาที่กำหนด
- หลังจากนั้นเมื่อใครบางคนมีความสนใจในการเลือกข้อมูลที่สื่อโดยแถวที่มีปัญหาเขาหรือเธอสามารถค้นหา "รุ่น" สองแบบที่แตกต่างกัน
ทางนี้:
- “ เวอร์ชั่น” ใดที่สามารถพิจารณาว่าถูกต้องเชื่อถือได้หรือไม่
- สิ่งใดสะท้อนให้เห็นถึงโลกแห่งความจริงอย่างแม่นยำ?
อย่างที่คุณทราบปรากฏการณ์นี้อาจมีผลทางกฎหมายซึ่งเป็นสถานการณ์ที่มีความสำคัญอย่างมาก
นอกจากนี้เวลาและความพยายามที่จะต้องใช้เพื่อจัดการกับความขัดแย้งดังกล่าว (อาจผ่าน“ การอัพเดทข้อมูลให้ตรงกัน” บางประเภท) ควรที่จะอุทิศให้กับงานที่สร้างคุณค่าให้กับองค์กรของคุณ ดังนั้นการรักษาแถวที่ขัดแย้งกันควรหลีกเลี่ยงโดยการออกแบบเพื่อให้ความสอดคล้องของฐานข้อมูลยังคงอยู่
นั่นคือเหตุผลที่การระบุคีย์หลัก (PK) และการประกาศของข้อ จำกัด ที่เกี่ยวข้องควรทำเสมอจะดำเนินการโดยนักออกแบบฐานข้อมูล แต่ต้องระบุด้วยเช่นกันว่าตารางอาจมีมากกว่าหนึ่งคอลัมน์หรือการรวมกันของคอลัมน์ที่เก็บค่าที่สามารถระบุได้ทุกแถว นอกเหนือจากการตั้งค่าข้อ จำกัด ของ PK (สร้างขึ้นในฐานะหลักเนื่องจากเหตุผลเชิงปฏิบัติ) ผู้ออกแบบจะต้องประกาศคีย์ ALTERATE หนึ่งตัวหรือมากกว่านั้น (โดยปกติจะกำหนดผ่านหนึ่งหรือมากกว่าหนึ่ง UNIQUE plus NOT NULL ข้อ จำกัด ) เมื่อใช้ (ซึ่งเป็น ค่อนข้างธรรมดา)
คุณสมบัติที่ได้เปรียบอีกประการหนึ่งของ PKs คือเมื่อ“ โอนย้าย” ไปยังตารางอื่นเพื่อมีส่วนร่วมใน FK เดี่ยวหรือคอมโพสิตพวกเขาสามารถช่วยในการบังคับใช้อัตราส่วนความสำคัญของความสัมพันธ์ที่มีอยู่ในข้อมูล ทั้งหมดนี้ใช่ด้วยวิธีการตั้งค่าที่เรียบง่ายและมีประสิทธิภาพซึ่งรับรองโดย DBMS
(ปัจจุบัน) ข้อ จำกัด การตรวจสอบและการตรวจสอบแถวเดียว
ขอให้เราอย่าลืมเกี่ยวกับความเกี่ยวข้องของข้อ จำกัด การตรวจสอบ (ในปัจจุบัน) ว่าการ จำกัด ชุดคอลัมน์ค่าของแถว (ซึ่งอาจดูง่าย แต่จริง ๆ แล้วเป็นคุณลักษณะพื้นฐานของ DBMS เชิงสัมพันธ์) ช่วยให้ มั่นใจว่ากฎของบริบททางธุรกิจสะท้อนให้เห็นถึงความแม่นยำตลอดเวลา
เมื่อคุณทำเครื่องหมายคำถามของคุณด้วยแท็ก MySQL จะต้องมีการกล่าวถึงว่าน่าเสียดายที่แพลตฟอร์มดังกล่าวอนุญาตให้มีการประกาศข้อ จำกัด ดังกล่าว แต่ในขณะเดียวกันก็เพิกเฉยต่อการบังคับใช้! สถานการณ์ที่เข้าใจได้รับรายงานว่าข้อผิดพลาดมาตั้งแต่ปี 2004
ในเรื่องนี้คุณจะต้องดูแลปัจจัยนี้ด้วยวิธีอื่นเช่นการทำธุรกรรมกรดทริกเกอร์หรือวิธีอื่น ๆ ภายใน DBMS เอง (ดูคำตอบนี้โดย@ ypercubeᵀᴹ
สำหรับข้อมูลเกี่ยวกับเรื่องนี้) เพื่อให้ข้อมูลดำเนินต่อไป คงเส้นคงวา.
ข้อ จำกัด ของการรับรอง: การตั้งค่ากฎธุรกิจแบบหลายแถวและหลายตารางเพิ่มเติมอย่างชัดเจน
แง่มุมหนึ่งที่ไม่ว่าด้วยเหตุผลใดก็ตามจะได้รับการสนับสนุนที่ไม่ดีอย่างมาก - ถ้าอย่างใดอย่างหนึ่ง - โดย SQL DBMSs ที่แตกต่างกันรวมถึง MySQL, กำลังเปิดใช้งานข้อ จำกัด หลายแถวและหลายตารางในรูปแบบที่ประกาศอย่างชัดเจน
สำหรับส่วนของมาตรฐาน SQL จะรวมถึง ASSERTIONs จากหลายปีที่ผ่านมา ฉันไม่ทราบว่ากฎของสภาพแวดล้อมทางธุรกิจของคุณจะได้รับประโยชน์จากวิธีการตรวจสอบความถูกต้องระดับตรรกะ แต่ในฐานะผู้ออกแบบฐานข้อมูลฉันคิดว่ามันจะค่อนข้างสะดวกในการ จำกัด ข้อมูลด้วยการรับรองอย่างน้อยหนึ่งข้อ มุมมองของนักพัฒนา DBMS เครื่องมือชนิดนี้เป็นเรื่องยากที่จะนำมาใช้ในระดับกายภาพของสิ่งที่เป็นนามธรรม
ปรากฏว่าผู้จำหน่าย Oracle และ / หรือนักพัฒนากำลังประเมินการสนับสนุน ASSERTION ตั้งแต่ปี 2559 และนั่นจะทำให้ DBMS สอดคล้องกับความสัมพันธ์มากขึ้นดังนั้นจึงมีความแข็งแกร่งและแข่งขันได้มากขึ้น ฉันเดาว่าหาก (i) ผู้บริโภคของพวกเขายังคงผลักดันและ (ii) Oracle ประสบความสำเร็จในการดำเนินการแล้ว (iii) ผู้ขาย / ชุมชน DBMS อื่น ๆ จะต้องเปิดใช้งานด้วยเช่นกันและการใช้งานของพวกเขาจะเริ่มแพร่กระจาย แน่นอนว่าจะเป็นความคืบหน้าอย่างมากในด้านการจัดการฐานข้อมูลและเป็นหนึ่งในเครื่องมือที่โดดเด่นที่สุดที่ดร. Codd คาดหวังไว้โดยส่วนตัวฉันหวังว่าเราจะเห็นสิ่งนั้นเกิดขึ้นในไม่ช้า
ความสอดคล้องของข้อมูลและกระบวนการตัดสินใจ
ดังที่กล่าวไว้ข้างต้นหนึ่งในแง่มุมที่สำคัญที่สุดของ RDB ก็คือมันรับประกันความสอดคล้องของข้อมูลที่เก็บรักษาไว้โดยตัวมันเองและความสอดคล้องดังกล่าวจะพบได้ก็ต่อเมื่อ RDB สอดคล้องกับข้อ จำกัด ด้านความสมบูรณ์ที่ประกาศโดยผู้สร้างโมเดล
ในแง่นี้มันเป็นภาคบังคับที่จะมีตารางฐาน (ที่สร้างขึ้นในโครงสร้าง DDL) ซึ่งความสมบูรณ์ของการป้องกันเพื่อให้สามารถสร้างตารางที่ได้รับ (เช่นคำสั่ง SELECT หรือมุมมองที่ดึงคอลัมน์จากหลายตาราง) ที่เชื่อถือได้เนื่องจากตารางที่ได้รับจะต้องมีการผลิตจำเป็นในแง่ของตารางฐาน
เป็นที่ทราบกันดีว่าคนใช้ข้อมูลเป็นเครื่องมือหลักในกระบวนการตัดสินใจขององค์กร (และในสามัญ) จากนั้นหากข้อมูลที่นำเสนอโดยฐานข้อมูลไม่สอดคล้องกันและถูกต้องการตัดสินใจบนพื้นฐานของข้อมูลดังกล่าวจะไม่ถูกต้อง นั่นคือเหตุผลที่ RDB จะต้องได้รับการออกแบบและนำไปใช้อย่างรอบคอบ: มันควรถูกสร้างขึ้นเพื่อให้เป็นทรัพยากรที่เชื่อถือได้ซึ่งสามารถช่วยผู้ใช้ในการตัดสินใจอย่างมีเหตุผล
“denormalization”
อนิจจา "ฐานข้อมูล 'denormalized' นั้นเร็วกว่าฐานข้อมูลปกติ 'เป็นความเข้าใจผิดที่แพร่หลายแม้ว่ามันจะเป็นข้อโต้แย้งที่สามารถหักล้างเหตุผลเชิงตรรกะทางกายภาพและทางปฏิบัติได้
ประการแรกdenormalizationหมายถึงจำเป็นต้องมีตารางฐานที่ได้รับการทำให้เป็นมาตรฐานก่อนหน้านี้ (โดยอาศัยกระบวนการที่เป็นทางการวิทยาศาสตร์พื้นฐานที่ปฏิบัติตามในระดับตรรกะของนามธรรมของฐานข้อมูล)
ดังนั้นสมมติว่าตารางดังกล่าวเป็นความจริงที่ถูกทำให้เป็นมาตรฐานได้อย่างปกติ“ denormalizing” มัน (ซึ่งตรงกันข้ามกับความหมายที่เป็นทางการของคำนั้นเกี่ยวข้องกับการผนวกเข้าไปในคอลัมน์ที่อยู่ในนั้นและยังเป็นส่วนหนึ่งของตารางอื่น ๆ ในโฆษณาด้วย hoc fashion) อาจช่วยเช่นเร่งความเร็ว (ในระดับกายภาพ) การประมวลผลของคำสั่ง SELECT หนึ่งหรือสองสามคำสั่งที่เฉพาะเจาะจงในขณะที่การกระทำดังกล่าวอาจทำให้การดำเนินการของข้อมูลที่เกี่ยวข้องอื่น ๆ การดำเนินการจัดการ (เช่นคำสั่ง INSERT, UPDATE, DELETE และ SELECT หลายคำสั่งหรือการรวมกันของคำสั่งเหล่านี้อยู่ในรายการธุรกรรมทางเดียวหรือหลายรายการ)
นอกจากนี้ denormalization (ไม่ว่าจะเป็นทางการหรือไม่เป็นทางการ) จะแนะนำความผิดปกติของการอัพเดท / แก้ไขที่เสื่อมสภาพการเชื่อมโยงของฐานข้อมูลปัญหาที่“ อาจ” ได้รับการจัดการโดยขั้นตอนที่ซับซ้อนราคาแพงและผิดพลาดได้ง่ายเมื่อทั้งหมดนี้สามารถป้องกันได้ จุดเริ่มต้นที่ดีมาก
โครงยกระดับทางกายภาพรองรับตารางที่ปรับให้เป็นมาตรฐานและ“ ลดความแปรปรวน”
รูปแบบเชิงตรรกะ (นามธรรม) (การออกแบบ SQL-DDL) ที่มีวัตถุประสงค์เพื่อใช้ในโลกแห่งความเป็นจริงอย่างชัดเจนถือผลกระทบทางกายภาพ (คอนกรีต) ที่จะต้องพิจารณา
ในลักษณะนี้ตาราง "denormalized" จะต้องเป็น "กว้าง" (ถือคอลัมน์เพิ่มเติม) ซึ่งหมายความว่าแถวของมันจะต้องหนักกว่า (ต้องการส่วนประกอบทางกายภาพระดับมากขึ้นและใหญ่กว่า) ดังนั้นนั่นหมายความว่ากระบวนการประมวลผลพื้นฐาน (เช่น ผู้ที่เกี่ยวข้องกับฮาร์ดไดรฟ์หรือหน่วยความจำ) สามารถทำให้ช้าลงได้อย่างง่ายดาย
ในทางตรงกันข้ามตารางปกติที่แน่นอนว่า "แคบลง" (มีคอลัมน์น้อยกว่า) จะเป็นองค์ประกอบ "เบา" (เสิร์ฟโดยองค์ประกอบทางกายภาพน้อยลง) ที่ "ทำงานเร็วขึ้น" ซึ่งจะเร่งความเร็วชุดการกระทำที่เกี่ยวข้องกับ เช่นการเขียนข้อมูลและการอ่าน
การทำเช่นนั้นจะสะดวกมากในการ (a) ทำให้มาตรฐานตารางที่เกี่ยวข้องเป็นปกติและรอบคอบทำให้เป็นเช่นนั้นและ (b) เพื่อใช้ทรัพยากรระดับกายภาพใด ๆ ที่สามารถเพิ่มประสิทธิภาพการดึงข้อมูลและความเร็วในการปรับเช่นการปรับใช้ กลยุทธ์การจัดทำดัชนีอย่างระมัดระวังและมีประสิทธิภาพเปิดใช้งานการกำหนดค่าซอฟต์แวร์และฮาร์ดแวร์เซิร์ฟเวอร์ที่เหมาะสมการอัพเกรดความสามารถแบนด์วิดท์เครือข่าย ฯลฯ
การทำงานของฐานข้อมูลภายใต้การพิจารณา
ย่อหน้าของคำถามของคุณเกี่ยวข้องกับความเร็วของการดำเนินการดึงข้อมูล:
[A] s ผลิตภัณฑ์ "ทำงาน" มีความลังเลที่จะปรับปรุงฐานข้อมูล; อย่างไรก็ตามสิ่งแรกที่ฉันสังเกตเห็นคือการใช้เวลาโหลดหน้าเว็บ 1 นาที (ใช่ 60 วินาที!)
หากการโหลดหน้าเว็บหนึ่งหน้านั้นใช้เวลามากนั้นจะเห็นได้ว่าผู้ใช้ระบบไม่ได้รับบริการที่ดี ดังนั้นแม้ว่ามันจะ“ ทำงาน” การทำงานของมันก็ไม่ได้ดีที่สุดเลยจุดที่แสดงให้เห็นว่าความตั้งใจของคุณที่จะทำให้สภาพแวดล้อมทั้งหมด (ฐานข้อมูลและแอพ) มีประสิทธิภาพมากขึ้นนั้นยั่งยืนและแสดงทัศนคติที่สร้างสรรค์มาก
จากนั้นแม้ว่าวิทยาศาสตร์จะสนับสนุนคุณอย่างแน่นอนและด้วยเหตุนี้คุณควรรักษาตำแหน่งที่มั่นคงฉันขอแนะนำให้คุณเข้าใกล้สถานการณ์ทางการทูตตั้งแต่สิ้นวันนายจ้างของคุณเพื่อนร่วมงานและตัวคุณเองก็พยายามเข้าร่วมเพื่อทำให้ทั้งองค์กร ประสบความสำเร็จมากขึ้น ดังนั้นนั่นคือเหตุผลหนึ่งที่คุณควรเน้นว่าในขณะที่พวกเขากำลังทำสิ่งอื่น ๆ ได้ดีกว่าการปรับปรุงการจัดการข้อมูลทั่วไปและเฉพาะเจาะจงอย่างมากสามารถช่วยในการสร้างการเติบโตขององค์กรและบุคคลมากขึ้น
ข้อความค้นหาที่เกี่ยวข้องส่วนใหญ่รวมการดำเนินการของ JOIN ซึ่งทำให้การทำงานช้ามากและช้ามากด้วยข้อมูลจำนวนมาก (ฐานข้อมูลมีจำนวนแถวนับล้าน)
เป็นสิ่งที่ควรสังเกตว่าตัวดำเนินการเข้าร่วมเป็นองค์ประกอบที่จำเป็นและมีประสิทธิภาพซึ่งเกี่ยวข้องกับการปรับเปลี่ยนข้อมูลเชิงสัมพันธ์ จากนั้นแม้ว่าแพลตฟอร์มที่แข็งแกร่งกว่าจะให้บริการด้วยการประหารชีวิตที่เร็วกว่า แต่สถานการณ์ที่คุณอธิบายน่าจะเป็นอาการที่เกิดจากการออกแบบที่ไม่เพียงพอ (ที่ระดับแนวคิดตรรกะและกายภาพของนามธรรม) ดังนั้นการประมาณพบครั้งแรกของฉันคือ:
- การตั้งค่า INDEX อาจต้องมีการปรับปรุง
- จำเป็นต้องตรวจสอบประเภทและขนาดคอลัมน์ PK และ FK (และฉันเห็นด้วยอย่างยิ่งกับ@Rick Jamesเกี่ยวกับการพิจารณา PK ของเขาเนื่องจากคีย์ผสมมีแนวโน้มที่จะมีประสิทธิภาพมากกว่าตัวแทนเสมือนในกรณีที่เหมาะสม)
- เพิ่มเติม (อย่างเป็นทางการบนพื้นฐานทางวิทยาศาสตร์) ฟื้นฟูอาจช่วยบรรเทาปัญหาเหล่านี้ในบัญชีของความเป็นจริงที่ว่าในสถานการณ์ที่เหมาะสม (เช่นดำเนินการใน RDB การออกแบบที่ดี) ร่วมจะดำเนินการอย่างรวดเร็ว
ยิ่งกว่านั้นใช่ว่า@TommCattกล่าวถึงคำตอบของเขาบางครั้งการเขียน (เชิงตรรกะ) ของแบบสอบถามจะปรับเปลี่ยนแผนการดำเนินการ (ทางกายภาพ) ที่เร่งการอ่าน / เขียนข้อมูลซึ่งเป็นปัจจัยที่ควรนำมาพิจารณาอย่างรอบคอบ