คำถามติดแท็ก denormalization

ฉันค่อนข้างใหม่ในการออกแบบฐานข้อมูลและฉันตัดสินใจที่จะสร้างฐานข้อมูลสมมุติของตัวเองเพื่อฝึกหัด อย่างไรก็ตามฉันมีปัญหาในการสร้างแบบจำลองและทำให้เป็นมาตรฐานในขณะที่ฉันเห็นว่ามีความสัมพันธ์แบบหลายต่อหลายคน (M: N) คำอธิบายภาพจำลองทั่วไป ฐานข้อมูลมีวัตถุประสงค์เพื่อเก็บข้อมูลเกี่ยวกับผู้คนที่ทำงานในซีรี่ส์ Zelda ฉันต้องการติดตามคอนโซลที่สามารถเล่นเกมได้พนักงานที่มีส่วนร่วมในการพัฒนาเกมงานที่พนักงานมี ( พนักงานหลายคนทำงานในงานที่แตกต่างกันในหลายเกม ) ฯลฯ กฎเกณฑ์ทางธุรกิจ หลายพนักงานสามารถทำงานได้ในหลายเกม หลายเกมสามารถอยู่บนเดียวกันคอนโซล Multiple Consolesสามารถเป็นแพลตฟอร์มสำหรับเกมเดียวกันได้ หลายพนักงานสามารถมีเหมือนกันงาน พนักงานสามารถมีหลายงาน เกมสามารถมีหลายพนักงาน เกมสามารถมีหลายประเภทของงานในการพัฒนาของมัน เกมหลายเกมสามารถแนบJobประเภทเดียวกันได้ คอนโซลสามารถมีหลายคนที่ทำงานกับมัน คนสามารถทำงานได้ในหลายConsoles ชื่อแอตทริบิวต์และค่าตัวอย่าง ชื่อพนักงานซึ่งสามารถแบ่งออกเป็นชื่อแรกและนามสกุล (เช่น“ John” และ“ Doe”) ชื่อเกม (ตัวอย่างเช่น "Ocarina of Time") ตำแหน่งงาน (ตัวอย่างเช่น "การออกแบบระดับ", "ผู้อำนวยการ", "ความสงบ", "ผู้ออกแบบระดับ", "โปรแกรมเมอร์", "การรองรับหลายภาษา" ฯลฯ ) ชื่อคอนโซล (ตัวอย่างเช่น“ Game Boy Advance”) …

16 database-design  normalization  denormalization  many-to-many 

ในระหว่างการประชุมรายสัปดาห์ครั้งล่าสุดของเราบุคคลที่ไม่มีประสบการณ์ด้านการบริหารฐานข้อมูลได้นำคำถามนี้มาใช้: "จะมีสถานการณ์สมมติที่จัดเก็บข้อมูลในบรรทัด (สตริง) แทนที่จะแสดงหลายบรรทัดหรือไม่" ให้เราสมมติตารางcountryStatesที่เราต้องการจัดเก็บสถานะของประเทศ ฉันจะใช้ USA เป็นตัวอย่างนี้และจะไม่แสดงรายการรัฐทั้งหมดเพื่อความเกียจคร้าน ที่นั่นเราจะมีสองคอลัมน์ หนึ่งเรียกว่าCountryและอื่น ๆ Statesที่เรียกว่า ตามที่กล่าวไว้ที่นี่และที่เสนอโดยของ @ srutzky คำตอบที่PKจะได้รับรหัสที่กำหนดโดยมาตรฐาน ISO 3166-1 alpha-3 ตารางของเราจะเป็นดังนี้: +---------+-----------------------+-------------------------------------------------------+ | Country | States | StateName | +---------+-----------------------+-------------------------------------------------------+ | USA | AL, CA, FL,OH, NY, WY | Alabama, California, Florida, Ohio, New York, Wyoming | +---------+-----------------------+-------------------------------------------------------+ เมื่อถามคำถามเดียวกันนี้ให้กับนักพัฒนาเพื่อนเขากล่าวว่าจากมุมมองขนาดทราฟฟิกข้อมูลนี่อาจมีประโยชน์ แต่ไม่ใช่ถ้าเราจำเป็นต้องจัดการข้อมูลนี้ ในกรณีนี้จะต้องมีความฉลาดในรหัสแอปพลิเคชันซึ่งสามารถแปลงสตริงนี้ในรายการ …

11 sql-server  database-design  denormalization 

ฉันกำลังสนทนาอย่างถาวรกับผู้พัฒนาของ บริษัท ที่ฉันทำงานอยู่เพราะพวกเขาบอกว่าเป็นการดีกว่าที่จะกำจัดการบังคับใช้ความสัมพันธ์ (ผ่านคำจำกัดความของคีย์ต่างประเทศ) ในฐานข้อมูลเชิงสัมพันธ์เพื่อเพิ่มความเร็วในการสืบค้นที่ใหญ่ขึ้น ประสิทธิภาพ. แพลตฟอร์มภายใต้การพิจารณาคือ MySQL 5.x และไม่มีการตั้งค่า KEY ต่างประเทศแม้ข้อ จำกัด หลักบางประการของตารางที่เกี่ยวข้องจะหายไปซึ่งอย่างน้อยสำหรับฉันก็ไม่สมเหตุสมผล อาจจะถูกและผิด แต่ฉันไม่มีข้อโต้แย้งเพียงพอที่จะพูดคุยเกี่ยวกับสถานการณ์นี้ นี่เป็นวิธีที่ได้รับความนิยมเป็นเวลาสามปีแล้ว ฉันใหม่ใน บริษัท นี้ (เพียงหนึ่งเดือน) แต่เป็นผลิตภัณฑ์ "งาน" มีลังเลที่จะปรับปรุงฐานข้อมูล ไม่เป็นไรสิ่งแรกที่ฉันสังเกตเห็นคือหน้าหนึ่งใช้เวลาโหลด 1 นาที (ใช่ 60 วินาที!) หนึ่งในข้อเรียกร้องที่อยู่เบื้องหลังสถานะของกิจการในปัจจุบันคือฐานข้อมูล“ denormalized” นั้นเร็วกว่าฐานข้อมูลปกติ แต่ฉันไม่เชื่อว่าเป็นเรื่องจริง ข้อความค้นหาที่เกี่ยวข้องส่วนใหญ่รวมการดำเนินการของ JOIN ซึ่งทำให้การทำงานช้ามากและช้ามากด้วยข้อมูลจำนวนมาก (ฐานข้อมูลมีจำนวนแถวนับล้าน) โดยทั่วไปการจัดการการดำเนินงาน "CRUD" ถูกนำไปใช้ในระดับรหัสโปรแกรมแอปพลิเคชัน ตัวอย่างเช่นในการลบข้อมูลบางส่วนจากสมมติว่าTableA: มีความจำเป็นต้องตรวจสอบครั้งแรกได้ทันทีหากมีความสัมพันธ์ระหว่างแถวของบางTableAและTableB, ในกรณีที่ความสัมพันธ์ดังกล่าว“ ตรวจพบ” แล้วรหัสโปรแกรมแอปจะไม่อนุญาตให้ลบแถวที่เกี่ยวข้องแต่ หากรหัสโปรแกรมแอปล้มเหลวด้วยเหตุผลบางอย่างการดำเนินการลบจะ“ สำเร็จ” ไม่ว่าจะมีความสัมพันธ์ใด ๆ …

10 mysql  database-design  normalization  relational-theory  denormalization