การทำให้ฐานข้อมูลเป็นปกติอยู่หรือไม่ [ปิด]

ฉันได้รับการเลี้ยงดูโรงเรียนเก่า - ที่เราเรียนรู้การออกแบบสคีมาฐานข้อมูลก่อนที่ชั้นธุรกิจของแอปพลิเคชัน (หรือใช้ OOAD สำหรับทุกอย่างอื่น) ฉันค่อนข้างดีกับการออกแบบ schemas (IMHO :) และปรับให้เป็นมาตรฐานเท่านั้นเพื่อลบความซ้ำซ้อนที่ไม่จำเป็นออกไป แต่ส่วนใหญ่มันไม่ใช่

ด้วยการถือกำเนิดของกรอบ ORM บางอย่างเช่น Ruby ActiveRecord หรือ ActiveJDBC (และอีกไม่กี่ฉันจำไม่ได้ แต่ฉันแน่ใจว่ามีมากมาย) ดูเหมือนว่าพวกเขาชอบที่จะมีคีย์ตัวแทนสำหรับทุกตารางแม้ว่าบางคนมีคีย์หลักเช่น 'email' - ทำลาย 2NF เอาล่ะ โอเคฉันเข้าใจไม่มากเกินไป แต่มันก็เกิดขึ้นในประสาทของฉัน (เกือบ) เมื่อ ORM เหล่านี้ (หรือโปรแกรมเมอร์) บางคนไม่ยอมรับ 1-1 หรือ 1-0 | 1 (เช่น 1 ถึง 0 หรือ 1) พวกเขากำหนดว่าจะดีกว่าที่จะมีทุกอย่างให้เป็นตารางขนาดใหญ่ไม่ว่าจะมีnulls "ระบบในปัจจุบันสามารถจัดการกับมันได้"เป็นความคิดเห็นที่ฉันได้ยินบ่อยขึ้น

ฉันยอมรับว่าข้อ จำกัด ของหน่วยความจำมีความสัมพันธ์โดยตรงกับการทำให้เป็นมาตรฐาน (มีประโยชน์อื่นเช่นกัน :) แต่ในวันนี้เวลากับหน่วยความจำราคาถูกและเครื่อง quad-core เป็นแนวคิดของการปรับสภาพฐานข้อมูล DB เพิ่งเหลือไว้กับตำรา? ในฐานะ DBA คุณยังคงฝึกการทำให้เป็นมาตรฐานอยู่ที่ 3NF (ถ้าไม่ใช่ BCNF :) มันสำคัญไหม การออกแบบ "schema สกปรก" นั้นดีสำหรับระบบการผลิตหรือไม่ เราควรทำให้เรื่องของ "มาตรฐาน" เป็นจริงได้อย่างไรถ้ามันยังเกี่ยวข้องกัน

( หมายเหตุ:ฉันไม่ได้พูดถึง schemas ดาว / เกล็ดหิมะของดาต้าแวร์เฮาส์ที่มีความซ้ำซ้อนเป็นส่วนหนึ่ง / ต้องการการออกแบบ แต่ระบบเชิงพาณิชย์ที่มีฐานข้อมูลแบ็กเอนด์เช่น StackExchange เป็นต้น)

เหตุผลหนึ่งสำหรับการทำให้เป็นมาตรฐานคือการลบความผิดปกติในการปรับเปลี่ยนข้อมูล
ORM มักไม่สนับสนุนสิ่งนี้

ฉันมีตัวอย่างมากมายของฐานข้อมูลที่ออกแบบโดยไฮเบอร์เนตที่ผิดหลักการนี้

• ป่อง (สตริงซ้ำมากกว่า 100 ล้านแถว)
• ไม่มีตารางการค้นหา (ดูด้านบน)
• ไม่มีDRI (ข้อ จำกัด กุญแจ)
• ดัชนีกลุ่มคลัสเตอร์ varchar
• ตารางลิงก์ที่ไม่จำเป็น (เช่นบังคับใช้ 1..0: 1 เมื่อคอลัมน์ FK ที่สามารถทำให้เป็นโมฆะได้)

ที่แย่ที่สุดที่ฉันเคยเห็นคือฐานข้อมูล MySQL 1TB ที่อาจใหญ่เกินไป 75-80% เพราะสิ่งเหล่านี้

ฉันขอแนะนำด้วยว่าคำว่า "ระบบในปัจจุบันสามารถจัดการได้" นั้นเป็นจริงสำหรับระบบมิกกี้เมาส์ส่วนใหญ่ ระบบของวันนี้จะไม่ทำงาน

ในตัวอย่างข้างต้นไม่มีการฉุดให้เปลี่ยนหรือเปลี่ยนคีย์หรือแก้ไขข้อมูล: เพียงแค่บ่นเกี่ยวกับอัตราการเติบโตของฐานข้อมูลและการไม่สามารถสร้าง DW ที่มีความหมายอยู่ด้านบน

ดูเหมือนว่าพวกเขาต้องการมีคีย์ตัวแทนสำหรับทุกตารางแม้ว่าบางคนมีคีย์หลักเช่น 'อีเมล' - ทำลาย 2NF ทันที

ปุ่มตัวแทนไม่ทำลาย 2NF 2NF พูดว่า "หากคอลัมน์ขึ้นอยู่กับส่วนหนึ่งของคีย์ที่มีหลายค่าเท่านั้นให้ลบคอลัมน์นั้นไปยังตารางแยกต่างหาก"

พวกเขากำหนดว่าจะดีกว่าที่จะมีทุกอย่างให้เป็นโต๊ะขนาดใหญ่ไม่ว่าจะมีโมฆะมากมาย

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

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

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

ตัวอย่างง่าย ๆ : สมมติว่าคุณรักษาข้อมูลโรงเรียนไว้ดังนี้:

กิจกรรมที่ 1: โรงเรียนมัธยม North Ridge, California, USA

กิจกรรมรับ 2: โรงเรียนมัธยมปลายโตรอนโตเบรฟออนแทรีโอแคนาดา

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

นี่เป็นหนึ่งในความสัมพันธ์ปกติ normalizing ช่วยป้องกันป้องกัน

แก้ไข: เปลี่ยนคำว่า Toronto เป็น Ontario ตามความคิดเห็นด้านล่าง

สิ่งที่เปลี่ยนแปลงมากขึ้นพวกเขาอยู่เหมือนกัน มีนักพัฒนาขี้เกียจอยู่เสมอที่ตัดมุมหรือแค่ไม่รู้หรือต้องการปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุด บ่อยครั้งที่พวกเขาสามารถหลบหนีด้วยแอปพลิเคชั่นขนาดเล็ก

มันเคยเป็นโครงสร้างข้อมูลที่ได้รับแรงบันดาลใจจากภาษาโคบอลเข้าสู่ RDBMS ในช่วงต้นหรือระเบียบที่แย่มาก ๆ ที่เป็น dBase ตอนนี้เป็น ORM และ "Code-First" ในท้ายที่สุดสิ่งเหล่านี้เป็นเพียงวิธีการที่ผู้คนพยายามค้นหากระสุนเงินจากการได้รับระบบการทำงานโดยไม่ต้อง "เสียเวลา" คิดหนักเกี่ยวกับสิ่งที่คุณต้องการและจำเป็นต้องทำ การรีบเป็นปัญหาเสมอและจะเป็นปัญหาเสมอ

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

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

ฉันยอมรับว่าการ จำกัด หน่วยความจำมีความสัมพันธ์โดยตรงกับการทำให้เป็นมาตรฐาน ...

ข้อ จำกัด ของหน่วยความจำยังคงมีความสำคัญ ปริมาณไม่ใช่ปัญหาความเร็วคือ

• ซีพียูไม่ได้เร็วขึ้นในขณะนี้ (เราได้รับคอร์มากขึ้นไม่ใช่รอบต่อวินาที)
• สถาปัตยกรรม CPU สมัยใหม่พยายามเอาชนะข้อ จำกัด ความเร็วโดยจัดให้มีหน่วยความจำแยกสำหรับแต่ละโปรเซสเซอร์ ( NUMA )
• ขนาดแคชที่ไม่ได้เพิ่มขึ้นในอัตราที่เทียบเท่ากับหน่วยความจำหลัก
• ปริมาณงานหน่วยความจำไม่สูงเท่าที่คนทั่วไปคาดหวัง QPIอยู่ในขอบเขต 25GB / วินาที

บางส่วนของพื้นดินนี้ได้รับการคุ้มครองในเมื่อใช้ TINYINT ผ่าน INT เมื่อใด ซึ่งคุณอาจพบว่ามีประโยชน์ ฉันขอแนะนำให้ติดตามการแสดงของ @ThomasKejser ( บล็อก ) จากทีม SQLCAT เนื่องจากพวกเขามีแนวโน้มที่จะผลักดันประสิทธิภาพการทำงานของฐานข้อมูล โพสต์เมื่อเร็ว ๆ นี้เกี่ยวกับผลกระทบของ CPU Caches และรูปแบบการเข้าถึงหน่วยความจำและการนำเสนอ SQLBits ในการสร้างแบบจำลองเชิงสัมพันธ์สำหรับ Extreme DW Scaleเป็นตัวอย่างที่ดี

ในความคิดของฉันก็ยังคงเป็นเพียงเกี่ยวกับความสมดุลระหว่างปกติและ de-ปกติ ฉันเห็นด้วยอย่างยิ่งว่ากรอบ ORM เป็นเพียงวิธีการทำสิ่งต่าง ๆ แต่ฉันไม่คิดว่ามันเป็นกรอบการทำงานเหล่านี้ที่ทำให้เกิดแนวโน้มที่ไม่เป็นปกติ

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

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

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

กล่าวอีกนัยหนึ่งวิธีการฟื้นฟูแบบมาตรฐานนั้นไม่ได้ตายไปอย่างแน่นอน แต่เมื่อเทียบกับวันเก่าที่มันถูกมองข้ามอย่างแน่นอน

CJ Date ตอบคำถามของคุณที่นี่ - วิดีโอมาตรฐาน (พรีเพลม) ฟรี

http://shop.oreilly.com/product/0636920025900.do

คำตอบสั้น ๆ : การทำให้เป็นมาตรฐานเป็นวิธีที่ถูกต้องทางคณิตศาสตร์ในการทำสิ่งต่าง ๆ หากคุณไม่ทำให้ปกติได้รูปแบบข้อมูลของคุณไม่ถูกต้อง