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

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

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

2
ฉันจะสลายตารางนี้โดยไม่สูญเปล่าได้หรือไม่?
ฉันสะดุดกับปัญหาการออกแบบฐานข้อมูลที่ไม่ได้อยู่ในลีกของฉันและกูรู DBA ของฉันที่ไปใช้ยังอยู่ในช่วงซ้อมหนีไฟ ในสาระสำคัญฉันมีตารางที่มีคีย์หลักต่อไปนี้ (PK สำหรับความกะทัดรัด): child_id integer parent_id integer date datetime child_idและparent_idเป็นกุญแจต่างประเทศในตารางกิจการ ตาราง "child" นั้นมี foreign key ไปยังตาราง "parent" และแท้จริงแล้วแต่ละตัวchild_idจะอ้างอิงเหมือนกันparent_idตามที่คาดไว้โดยตารางข้างต้น ในความเป็นจริงปรากฎว่ามีโค้ดพิเศษบางอย่างที่ทำให้ทั้งสองซิงค์กันอยู่ ซึ่งทำให้สามเณรการปรับสภาพ overenthusiastic นี้พูดว่า "ฉันควรลบความซ้ำซ้อนแทน!" ฉันย่อยสลายต่อไปนี้: Table_1 PK: child_id integer date datetime Table_2 PK: parent_id integer date datetime Table_3: (already exists) child_id integer PRIMARY KEY parent_id integer FOREIGN KEY …

2
กดไลค์หรือโหวตโพสต์
ฉันกำลังสร้างโปรแกรมขนาดเล็กที่ผู้ใช้โพสต์หรือเขียนบล็อก ในโพสต์เหล่านั้นผู้ใช้รายอื่นสามารถชอบหรือไม่ชอบโพสต์ดังกล่าวในเฟสบุ๊คหรือโพสต์โหวตลงหรือโพสต์ลงโพสต์ในสแต็คโอเวอร์โฟลว์ ฉันอยากจะรู้โครงสร้างฐานข้อมูลที่ดีซึ่งใช้กันทั่วไปและโปรแกรมทำงานอย่างมีประสิทธิภาพกับโครงสร้างนั้น ฉันมีสองตัวเลือก เป็นครั้งแรก โพสต์: id head message datepost likes dislikes 1 ab anchdg DATE 1,2,3 7,55,44,3 ในทางข้างต้นidเป็น postid ในคอลัมน์1,2,3ไลค์คือรหัสของผู้ใช้ที่ชอบหรืออัปเดตโพสต์หรือบล็อก 7,55,44,3คือรหัสของผู้ใช้ที่ไม่ชอบหรือลดระดับโพสต์หรือบล็อก ที่สอง โพสต์: id head message datepost 1 ab anchdg DATE ชอบอะไร: id postid userid 1 1 1 2 2 2 ไม่ชอบ: id postid userid 1 1 7 2 …

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

4
ฟอร์มปกติแรก: คำจำกัดความที่ชัดเจน
ฉันกำลังพยายามรับรุ่นที่ชัดเจนของแบบฟอร์มปกติที่หนึ่งคืออะไร ทุกสิ่งที่ฉันอ่านมีการหมุนที่แตกต่างกันเล็กน้อย เจ้าหน้าที่หลายคนเช่นวันที่บอกว่าตามคำจำกัดความความสัมพันธ์อยู่ในรูปแบบปกติครั้งแรกในขณะที่คนอื่น ๆ ให้รายการข้อกำหนด ซึ่งหมายความว่ามีตั้งแต่ศูนย์ถึงข้อกำหนดจำนวนมากสำหรับ 1NF ฉันคิดว่าความแตกต่างคือระหว่างตารางและความสัมพันธ์: ตารางสามารถเป็นระเบียบสมบูรณ์ในขณะที่ความสัมพันธ์ตามข้อ จำกัด บางอย่าง ข้อเท็จจริงที่ว่าความสัมพันธ์นั้นแสดงเป็นตารางใน SQL จึงสร้างความสับสนบางอย่าง ฉันมุ่งเน้นไปที่ 1NF โดยเฉพาะเนื่องจากเกี่ยวข้องกับฐานข้อมูล SQL คำถามคือ: คุณสมบัติใดที่จำเป็นเพื่อให้แน่ใจว่าตารางที่อยู่ในรูปแบบปกติครั้งแรก? เจ้าหน้าที่หลายคนแนะนำว่าหากตารางแสดงถึงความสัมพันธ์แสดงว่าเป็น 1NF แล้ว สิ่งนี้จะผลักดันความหมายของ 1NF กลับไปที่ความหมายของความสัมพันธ์ นี่คือคุณสมบัติบางส่วนของตารางใน 1NF: ลำดับคอลัมน์ไม่มีความสำคัญ [1] ลำดับแถวไม่มีนัยสำคัญ แถวทั้งหมดมีความยาวเท่ากัน (เช่นข้อมูลแถวตรงกับส่วนหัวของคอลัมน์) ไม่มีแถวที่ซ้ำกัน (สามารถรับประกันได้โดยใช้คีย์หลักของตัวแทนตัวแทน แต่ไม่จำเป็นต้องใช้ PK เอง) ไม่มีคอลัมน์ซ้ำกัน แต่ละคอลัมน์มีค่าเดียว (อะตอมมิก) [1] แอททริบิวต์ทางเทคนิคไม่ได้เรียงลำดับ แต่ในตารางข้อมูลแถวจะต้องอยู่ในลำดับเดียวกับส่วนหัวของคอลัมน์ อย่างไรก็ตามคำสั่งซื้อที่แท้จริงนั้นไม่มีนัยสำคัญ ในหลายข้อมูล : แนวคิดของข้อมูลอะตอมคือไอเท็มไม่สามารถแยกย่อยได้อีก แนวคิดนี้ได้รับการมีคุณสมบัติในการว่าถึงแม้ในทางเทคนิคทุกอย่างได้ถูกทำลายลงnauseum โฆษณาข้อมูลในคำถามที่ไม่สามารถจริงเสียลงเพิ่มเติมใด …

1
การออกแบบโครงสร้างฐานข้อมูลมิตรภาพ: ฉันควรใช้คอลัมน์ที่มีหลายค่าหรือไม่
ว่าฉันมีตารางที่เรียกว่าUser_FriendListซึ่งมีลักษณะดังต่อไปนี้: CREATE TABLE User_FriendList ( ID ..., User_ID..., FriendList_IDs..., CONSTRAINT User_Friendlist_PK PRIMARY KEY (ID) ); และให้เราสมมติว่าตารางดังกล่าวถือข้อมูลต่อไปนี้: + ---- + --------- + --------------------------- + | ID | User_ID | Friendlist_ID | + ---- + --------- + --------------------------- + | 1 | 102 | 2: 15: 66: 35: 26: 17: | + …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.