mysql - จำนวนคอลัมน์มากเกินไป?


111

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

ณ จุดใดถือว่ามีจำนวนคอลัมน์มากเกินไปหรือไม่


6
เราไม่ต้องใช้ SELECT * ตลอดเวลา เรามีตัวเลือกให้เลือกเฉพาะคอลัมน์ที่เราต้องการสำหรับสถานการณ์นั้น ๆ
APC

3
70 คอลัมน์?! จำนวนที่ไม่สามารถเป็นโมฆะได้?
OMG Ponies

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

2
@ กม. นั่นควรจะเป็นเรื่องตลกหรือไม่? ฉันยังใหม่กับ MySQL และไม่สามารถรับได้คุณหมายความว่า JOIN เป็นสิ่งที่ดีหรือเป็นสิ่งที่ควรพยายามหลีกเลี่ยง?
Elia Iliashenko

2
เนื่องจากการรวมเป็นส่วนหลักของ SQL การเข้าร่วมเพื่อประโยชน์ในการเข้าร่วมอาจลดประสิทธิภาพและความสามารถในการบำรุงรักษาสำหรับแอปพลิเคชันใดก็ตามที่คุณมี
jeteon

คำตอบ:


142

ก็ถือว่ามากเกินไปเมื่อมีการดังกล่าวข้างต้นขีด จำกัด สูงสุดการสนับสนุนจากฐานข้อมูล

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

ตามกฎทั่วไปโครงสร้างตารางของคุณควรสะท้อนถึงรูปแบบโดเมนของคุณ ถ้าคุณมีแอตทริบิวต์ 70 (100 คุณมีอะไรบ้าง) ที่เป็นของเอนทิตีเดียวกันก็ไม่มีเหตุผลที่จะแยกพวกมันออกเป็นหลายตาราง


29
@KM - นั่นคือเหตุผลที่ฉันพูดว่า "แอตทริบิวต์ที่เป็นของเอนทิตีเดียวกันในแบบจำลองโดเมน" คอลัมน์จำนวนมากในตารางไม่ได้ทำให้มันถูกทำให้ผิดปกติ มันคือสิ่งที่กล่าวว่าคอลัมน์แสดงถึงสิ่งนั้นสำคัญ นอกจากนี้ในขณะที่การทำให้เป็นมาตรฐานเป็นสิ่งที่ดี แต่ก็ไม่ใช่วิธีแก้ปัญหาในชีวิตทั้งหมด คำถามหลอก - คุณคิดว่าจำนวนโหวตถัดจากคำถาม / คำตอบ SO ถูกคำนวณเหมือนselect count(*) from votesทุกครั้งหรือคุณคิดว่ามันอาจจะถูกทำให้ผิดปกติ? นั่นทำให้ฐานข้อมูล SO ไม่ดีและ Jeff Atwood บ้าหรือไม่?
ChssPly76

@ ChssPly76 เป็นฐานข้อมูลเชิงสัมพันธ์ไม่ใช่แบบจำลองวัตถุ มีตารางแถวและคอลัมน์ทำงานภายในข้อ จำกัด นั้นหากคุณต้องการประสิทธิภาพสูงสุดเลียนแบบวัตถุของคุณเพื่อความสะดวกในการทำงาน ดังนั้นข้อมูลทุกชิ้นเกี่ยวกับบุคคลควรเก็บไว้ในแถวเดียวกันหรือไม่? ไม่แยกพวกเขาออกและจัดกลุ่มเป็นตารางต่างๆ (โดยใช้ตัวอย่างของฉันจากความคิดเห็นก่อนหน้าของฉัน): "บุคคล", "กิจกรรม" "HealthRecords" การจัดเก็บ SUM ด้วยเหตุผลด้านประสิทธิภาพเป็นปัญหาที่แตกต่างอย่างสิ้นเชิงกับการเก็บข้อมูลทั้งหมดใน 70 คอลัมน์เพื่อหลีกเลี่ยงการรวม
กม ธ .

20
"numberOfTeethPulled" ควรเป็นส่วนหนึ่งของบันทึกบุคคลหรือไม่ ไม่มันอาจจะไม่ควรจัดเก็บเลยคุณจะได้รับข้อมูลนั้นจาก "ToothExtractionRecord" หากโมเดลโดเมนของคุณต้องการรายละเอียดในระดับดังกล่าว แต่นั่นคือตัวอย่างของคุณ (และฉันกล้าที่จะพูดว่าค่อนข้างคิดขึ้น) - มันไม่เกี่ยวข้องกับประเด็นของฉัน: คอลัมน์จำนวนมากในตารางไม่ได้หมายความว่าตารางจะถูกทำให้เป็นมาตรฐาน ลองนึกถึงสัญญาอสังหาริมทรัพย์ / ใบสั่งซื้อ / เอกสารทางการเงินอื่น ๆ เพื่อบอกตัวอย่างบางส่วน สามารถแบ่งออกเป็นหลายตารางได้หรือไม่? ใช่. มีเหตุผลอะไรบ้าง? ไม่จริง
ChssPly76

1
+1 นั่นก็เฮฮา หากคุณกำลังสร้างตารางอื่นและมันจะเป็นความสัมพันธ์แบบ 1: 1 คุณก็น่าจะรวมไว้ในตารางหลัก มันจะไม่ช่วยประหยัดพื้นที่มันจะไม่ทำงานได้ดีกว่านี้ถ้าคุณไม่ขอข้อมูลเทียบกับมันไม่ได้อยู่ในตารางเลย เหตุผลเดียวที่อยู่ในใจสำหรับฉันตอนนี้คือหากมีข้อมูลที่ละเอียดอ่อนอยู่ในนั้นเช่น SSN ข้อมูลบัตรเครดิต ฯลฯ ...
Vandel212

1
ถ้าฉันมีตารางหนึ่งมี 15 cols และอีกตารางหนึ่งมี 300 cols คีย์หลักของทั้งสองตารางจะเหมือนกัน เลือกหนึ่งคอลัมน์ในสองตารางประสิทธิภาพจะแตกต่างกันมากหรือไม่?
ข้อเสนอไม่สามารถปฏิเสธ

28

มีประโยชน์บางอย่างที่จะแยกตารางที่มีอยู่ในหลายที่มีคอลัมน์น้อยลงซึ่งจะเรียกว่าแนวตั้งพาร์ทิชัน นี่คือบางส่วน:

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

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

  3. ตารางที่กว้างขึ้นอาจทำให้ประสิทธิภาพการสืบค้นช้าลง

อย่าเพิ่มประสิทธิภาพก่อนเวลาอันควร แต่ในบางกรณีคุณจะได้รับการปรับปรุงจากตารางที่แคบลง


5
เหตุใด MySQL จึงต้องสร้างดัชนีทั้งหมดในตารางใหม่หากมีการแก้ไขเพียงรายการเดียว
Petr Peller

ฉันก็สงสัยเหมือนกัน ทำไม MySQL จึงสร้างดัชนีทั้งหมดในตารางขึ้นมาใหม่ คำกล่าวข้างต้นถูกต้องหรือไม่?
พ.

13

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

ใช้กฎต่อไปนี้กับตารางแบบกว้างและคุณจะมีคอลัมน์น้อยกว่ามากในตารางเดียว

  1. ไม่มีองค์ประกอบซ้ำหรือกลุ่มขององค์ประกอบ
  2. ไม่มีการอ้างอิงบางส่วนบนคีย์ที่ต่อกัน
  3. ไม่มีการพึ่งพาแอตทริบิวต์ที่ไม่ใช่คีย์

นี่คือลิงค์ที่จะช่วยคุณได้


17
It is pretty hard to get that many columns if you are normalizing your database.ไม่ยากอย่างที่คิด
Petr Peller

5
ไม่ยากแน่นอน ผู้คนดูเหมือนจะไม่เข้าใจรูปแบบปกติของส่วนต่างๆที่นี่ คุณสามารถมี 10,000 คอลัมน์และยังคงถูกทำให้เป็นมาตรฐาน (แม้กระทั่งในรูปแบบปกติสูงสุด)
Hejazzman

2
@foljs และนั่นคือจุดที่การปฏิบัติที่ยอมรับในการทำให้เป็นภาวะปกติเกิดขึ้นหากคุณอยู่ที่สี่แยกและมีรถกำลังจะขับเข้ามาหาคุณคงเป็นเรื่องโง่ที่จะรอให้ไฟเปลี่ยนเป็นสีเขียว คุณต้องหลีกทางให้ได้ ในขณะที่ฝ่าไฟแดงอาจไม่ถูกกฎหมายในทางเทคนิคคุณกำลังทำในสิ่งที่คุณควรทำอย่างชัดเจนเนื่องจากสถานการณ์ = denormalization
user3308043

3
คุณทำให้ฉันหายไปเมื่อคุณเริ่มพูดถึงรถยนต์ ไม่รู้ว่าความเกี่ยวข้องคืออะไร
JohnFx

2
อย่างไรก็ตามคุณจะทำแบบสอบถามที่ซับซ้อนในสถานการณ์นี้ด้วยตารางข้อมูลเดียวได้อย่างไรคุณไม่สามารถทำได้คุณต้องพึ่งพาภาษาโปรแกรมและสิ่งอื่น ๆ อีกมากมายเพื่อให้ทำงานได้! ดังนั้นฉันอาจจะกลับไปมีตารางที่มี 170 คอลัมน์เนื่องจากการมีคำค้นหา "JOIN" และการเขียนโปรแกรมที่ซับซ้อนเป็นพิเศษซึ่งจำเป็นต้องทำให้ตารางแยกกันทำงานได้ดูเหมือนว่าฉันจะเสียเวลา ฉันเดาว่าฉันเป็นแฟนตัวยงของหลักการ KISS
Vlad Vladimir Hercules

0

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


0

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.