ข้อใดมีประสิทธิภาพมากกว่า: ตาราง MySQL หลายตารางหรือตารางขนาดใหญ่

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

• นี่จะเป็นการช่วยเหลือหรือขัดขวาง?
• ข้อควรพิจารณาเกี่ยวกับความเร็วในการโทรอัปเดตหรือค้นหา / จัดการ?

นี่คือตัวอย่างโครงสร้างตารางบางส่วนของฉัน:

• ผู้ใช้ - UserId, ชื่อผู้ใช้, อีเมล, รหัสผ่านที่เข้ารหัส, วันที่ลงทะเบียน, ip
• user_details - ข้อมูลคุกกี้ชื่อที่อยู่รายละเอียดการติดต่อความร่วมมือข้อมูลประชากร
• user_activity - การมีส่วนร่วมออนไลน์ล่าสุดการดูครั้งล่าสุด
• user_settings - การตั้งค่าการแสดงโปรไฟล์
• user_interests - โฆษณาตัวแปรที่กำหนดเป้าหมายได้
• user_levels - สิทธิ์การเข้าถึง
• user_stats - hit, tallies

แก้ไข:ฉันได้ให้คะแนนคำตอบทั้งหมดจนถึงตอนนี้พวกเขาทั้งหมดมีองค์ประกอบที่ตอบคำถามของฉันเป็นหลัก

ตารางส่วนใหญ่มีความสัมพันธ์แบบ 1: 1 ซึ่งเป็นสาเหตุหลักในการทำให้ผิดปกติ

จะมีปัญหาหรือไม่หากตารางครอบคลุมมากกว่า 100 คอลัมน์เมื่อเซลล์เหล่านี้ส่วนใหญ่น่าจะว่างเปล่า

หลายตารางช่วยในวิธี / กรณีต่อไปนี้:

(ก) หากต่างคนต่างกำลังจะพัฒนาแอปพลิเคชันที่เกี่ยวข้องกับตารางที่แตกต่างกันก็ควรแยกออก

(b) หากคุณต้องการมอบหน่วยงานที่แตกต่างกันให้กับบุคคลอื่นสำหรับส่วนต่างๆของการรวบรวมข้อมูลการแยกพวกเขาอาจสะดวกกว่า (แน่นอนคุณสามารถดูการกำหนดมุมมองและการให้สิทธิ์ได้อย่างเหมาะสม)

(c) สำหรับการย้ายข้อมูลไปยังที่ต่างๆโดยเฉพาะอย่างยิ่งในระหว่างการพัฒนาอาจเหมาะสมที่จะใช้ตารางที่ทำให้ไฟล์มีขนาดเล็กลง

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

(จ) มีความเป็นไปได้: สิ่งที่คุณคิดว่าเป็นข้อมูลค่าเดียวอาจกลายเป็นหลายค่าได้ในอนาคต เช่นวงเงินสินเชื่อเป็นฟิลด์ค่าเดียว ณ ตอนนี้ แต่พรุ่งนี้คุณอาจตัดสินใจเปลี่ยนค่าเป็น (วันที่จากวันที่ถึงมูลค่าเครดิต) ตารางแยกอาจเป็นประโยชน์ในตอนนี้

การโหวตของฉันคือสำหรับหลาย ๆ ตาราง - โดยแบ่งข้อมูลอย่างเหมาะสม

โชคดี.

การรวมตารางเรียกว่า denormalizing

อาจ (หรือไม่ก็ได้) ช่วยในการสร้างแบบสอบถาม (ซึ่งมีจำนวนมากJOIN) เพื่อให้ทำงานได้เร็วขึ้นโดยเสียค่าใช้จ่ายในการสร้างขุมทรัพย์การบำรุงรักษา

MySQLสามารถใช้JOINวิธีเดียวคือNESTED LOOPS.

ซึ่งหมายความว่าสำหรับแต่ละระเบียนในตารางการขับขี่ให้MySQLค้นหาระเบียนที่ตรงกันในตารางที่ขับเคลื่อนในแบบวนซ้ำ

การค้นหาบันทึกเป็นการดำเนินการที่มีค่าใช้จ่ายค่อนข้างสูงซึ่งอาจใช้เวลานานหลายสิบเท่าในการสแกนเร็กคอร์ดทั้งหมด

การย้ายบันทึกทั้งหมดของคุณไปไว้ในตารางเดียวจะช่วยให้คุณกำจัดการดำเนินการนี้ได้ แต่ตารางจะมีขนาดใหญ่ขึ้นและการสแกนตารางใช้เวลานานขึ้น

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

ในทางกลับกันรับประกันนรกการบำรุงรักษา

พวกเขาทั้งหมดมีความสัมพันธ์แบบ 1: 1 หรือไม่? ฉันหมายความว่าถ้าผู้ใช้สามารถอยู่ในระดับของผู้ใช้ที่แตกต่างกันหรือหากความสนใจของผู้ใช้แสดงเป็นหลายระเบียนในตารางความสนใจของผู้ใช้การรวมตารางเหล่านั้นจะไม่เป็นปัญหาทันที

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

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

ทำทั้งหมดของตารางเหล่านั้นมี1-to-1ความสัมพันธ์? ตัวอย่างเช่นแต่ละแถวของผู้ใช้จะมีเพียงแถวเดียวในuser_statsหรือuser_levels? ถ้าเป็นเช่นนั้นการรวมไว้ในตารางเดียวอาจเป็นเรื่องที่สมเหตุสมผล ถ้าความสัมพันธ์ไม่ได้ 1 to 1เช่นนั้นก็คงไม่สมเหตุสมผลที่จะรวม (ทำให้เป็นปกติ) เข้าด้วยกัน

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

ETA:

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

หากคุณดูวิธีที่คุณใช้ข้อมูลฉันเดาว่าคุณจะพบว่า 80% ของข้อความค้นหาของคุณใช้ข้อมูลนั้น 20% โดยที่ข้อมูลที่เหลืออีก 80% จะถูกใช้เป็นครั้งคราวเท่านั้น รวม 20% ที่ใช้บ่อยไว้ในตารางเดียวและปล่อยให้ 80% ที่คุณไม่ได้ใช้บ่อยๆในตารางแยกต่างหากและคุณอาจมีการประนีประนอมที่ดี

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

แก้ไข: ฉันได้อัปเดตคำตอบของฉันแล้วเนื่องจากคุณได้อัปเดตคำถามของคุณ ... ฉันเห็นด้วยกับคำตอบเริ่มต้นของฉันมากยิ่งขึ้นตั้งแต่ตอนนี้ ...

เซลล์เหล่านี้ส่วนใหญ่น่าจะยังว่างอยู่

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

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

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

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

ฉันคิดว่านี่เป็นหนึ่งในสถานการณ์ที่ "ขึ้นอยู่กับ" การมีโต๊ะหลายโต๊ะนั้นสะอาดกว่าและน่าจะดีกว่าในทางทฤษฎี แต่เมื่อคุณต้องเข้าร่วม 6-7 ตารางเพื่อรับข้อมูลเกี่ยวกับผู้ใช้คนเดียวคุณอาจเริ่มคิดใหม่ในแนวทางนั้น

ฉันจะบอกว่ามันขึ้นอยู่กับความหมายของตารางอื่น ๆ จริงๆ user_details มีมากกว่า 1 มากกว่า / ผู้ใช้และอื่น ๆ การปรับมาตรฐานระดับใดที่เหมาะสมที่สุดสำหรับความต้องการของคุณขึ้นอยู่กับความต้องการของคุณ

หากคุณมีตารางเดียวที่มีดัชนีที่ดีซึ่งอาจเร็วกว่า แต่ในทางกลับกันอาจดูแลรักษายากกว่า

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