จำเป็นหรือไม่ในการสร้างฐานข้อมูลที่มีตารางน้อยที่สุด

เราควรสร้างโครงสร้างฐานข้อมูลด้วยจำนวนตารางขั้นต่ำหรือไม่

ควรออกแบบในลักษณะที่ทุกอย่างอยู่ในที่เดียวหรือไม่หรือมีตารางเพิ่มขึ้น?

จะมีผลกับสิ่งใดหรือไม่

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

แก้ไข

ฉันกำลังสรุปคำตอบเมื่อ: ขนาดของตารางไม่สำคัญจนกว่าจะถึงกรณีพิเศษ ในกรณีนี้การทำให้เป็นปกติอาจช่วยได้

ขอบคุณทุกคนสำหรับคำตอบ

IGNOREจำนวนของตาราง กังวลเกี่ยวกับการออกแบบให้ถูกต้องมากขึ้น หากข้อกังวลหลักของคุณคือปริมาณของตารางคุณอาจไม่ควรออกแบบระบบฐานข้อมูล

หากเพื่อนของคุณต้องการเพียง 8 ตารางและระบบทำงานได้ดีกับที่นั้น 8 คือหมายเลขที่ถูกต้องและ 12 ที่เหลืออาจไม่จำเป็นสำหรับสิ่งที่เขาทำ

ข้อยกเว้นที่เป็นไปได้อาจเป็นสภาพแวดล้อมที่แปลกประหลาดที่มีข้อ จำกัด อย่างหนักเกี่ยวกับหมายเลขตาราง แต่ฉันไม่สามารถนึกถึงตัวอย่างที่เป็นรูปธรรมของระบบดังกล่าวที่อยู่ด้านบนของหัวของฉัน

ฐานข้อมูลควรมีตารางมากเท่าที่ต้องการ ไม่น้อยไปกว่านี้อีกแล้ว

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

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

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

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

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

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

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

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

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

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

การมีจำนวนตารางน้อยที่สุดทำให้ฉันเป็นเป้าหมายที่แปลกประหลาดมาก

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

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

แน่นอนว่ามันสามารถนำไปสู่การทำงานที่ช้าลงได้

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

หมายเลขไม่สำคัญ การออกแบบคือ ดูระบบบางอย่างที่นั่น Magento, PHPBB และอื่น ๆ พวกเขามีหลายสิบตารางในระบบของพวกเขาและทำงานได้ดี

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

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

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

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

ฉันจะไม่เข้าไปดูรายละเอียด แต่ฉันคิดว่าความจริงที่ว่าจำนวนตารางสามารถมีอิทธิพลต่อประสิทธิภาพเป็นหนึ่งในเหตุผลที่ฐานข้อมูล noSQL เช่น Cassandra, Mongo และ Google BigTable (sic!) ได้ถูกประดิษฐ์ขึ้น และนั่นเป็นสาเหตุที่พวกเขาสนับสนุนการลดความซ้ำซ้อนของข้อมูล (และหลีกเลี่ยงตาราง / คอลเลกชันจำนวนมาก ฯลฯ )

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

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

ลุงบ๊อบจะโต้แย้งว่า More นั้นเรียบง่ายกว่า

ดูhttp://c2.com/cgi/wiki?FearOfAddingTables

"การออกแบบที่ดีโดยทั่วไปจะทำให้ง่ายขึ้นโดยการเพิ่มตาราง"

ฉันเชื่อว่าหน่วยงานเกือบทั้งหมดเป็นกลุ่มต่อกลุ่มซึ่งต้องใช้ตารางมากขึ้น

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

จากนั้นคำตอบคือใช่

แต่ขึ้นอยู่กับความหมายที่แท้จริงของจำนวนตาราง "ขั้นต่ำ" คืออะไร

ตัวอย่างเช่น (ตัวอย่างต่อต้าน)

ถ้าฉันมีวัตถุต่อไป

1. ผู้ใช้
2. ลูกค้า

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

1. table_persons

ค่อนข้างสองตารางที่แตกต่างกัน

1. table_users
2. table_customers

ข้อเสียคือใน table_persons เราจะต้องเพิ่มฟิลด์ใหม่ (type_of_person)

ข้อผิดพลาดอื่น ๆ (ข้อผิดพลาดหากไม่จำเป็นต้องทำจริงๆ) คือการ "แยก" ตารางอ่านเป็น: แยกตารางเดียวออกเป็นสองส่วน

1. table_persons

ในสองตาราง

1. table_info_persons
2. table_extra_info_persons

เนื่องจากคุณกำลังบังคับให้มีการสอบถามเพื่อเข้าร่วมสองตารางและมันไม่ดี