สิ่งที่น่าสนใจเกี่ยวกับคำถามและคำตอบของกระทู้นี้คือมีคำถาม 3 ข้อ ทุกคนตอบคำถามแตกต่างกันและแทบจะไม่มีใครตอบคำถามแรกได้:
- ทำไมจะไม่ได้ฐานข้อมูลบางอย่างในป่าปกติ?
- ทำไม / เมื่อควรจะเป็นฐานข้อมูลที่ปกติจะdenormalized ?
- ในสถานการณ์ใดบ้างที่เป็นอันตรายหรือไม่จำเป็นที่จะต้องทำให้เป็นมาตรฐานในตอนแรก?
ผู้อ่านที่แจ้งเตือนจะทราบว่าคำถามเหล่านี้แตกต่างกันมากและฉันจะพยายามตอบคำถามแต่ละข้อแยกกันโดยหลีกเลี่ยงรายละเอียดมากเกินไป โดย "มากเกินไป" ฉันหมายความว่าฉันไม่คิดว่านี่เป็นบริบทที่เหมาะสมที่จะทำการอภิปรายเพิ่มเติมเกี่ยวกับข้อดีของข้อโต้แย้งต่าง ๆ เพื่อสนับสนุนหรือต่อต้านการทำให้เป็นมาตรฐาน ฉันแค่จะอธิบายว่าข้อโต้แย้งเหล่านั้นคืออะไรเขียนรายการคำเตือนสักสองสามข้อและบันทึกปรัชญาสำหรับคำถามที่เฉพาะเจาะจงมากขึ้นหากพวกเขาเคยเกิดขึ้น
นอกจากนี้ในคำตอบนี้ฉันสมมติว่า"การทำให้เป็นมาตรฐาน"หมายถึง"BCNF, 3NF หรืออย่างน้อย 2NF"เนื่องจากเป็นระดับของการทำให้เป็นมาตรฐานที่ผู้ออกแบบมักจะบรรลุ มันยากที่จะเห็นการออกแบบ 4NF หรือ 5NF; แม้ว่าพวกเขาจะไม่ใช่เป้าหมายที่เป็นไปไม่ได้อย่างแน่นอน แต่พวกเขาก็กังวลกับความหมายของความสัมพันธ์มากกว่าแค่การเป็นตัวแทนของพวกเขาซึ่งต้องการความรู้มากขึ้นเกี่ยวกับโดเมน
ดังนั้นเป็นต้นไปและขึ้นไป:
1. ทำไมฐานข้อมูลบางส่วนใน wild จึงไม่ได้มาตรฐาน
คำตอบสำหรับเรื่องนี้อาจเป็น "เพราะพวกเขาไม่ควรเป็น" แต่การทำให้สมมติฐานนั้นถูกต้องเป็นงานนักสืบที่น่าสงสาร เราจะไม่ก้าวหน้าอย่างมากในฐานะสังคมหากเราดำเนินการตามข้อสันนิษฐานเสมอว่าสิ่งใดก็ตามที่ควรจะเป็น
เหตุผลที่แท้จริงที่ฐานข้อมูลไม่ได้รับการทำให้เป็นมาตรฐานในตอนแรกมีความซับซ้อนมากขึ้น นี่คือ 5 อันดับแรกที่ฉันเจอ:
นักพัฒนาที่ออกแบบมันไม่รู้หรือไม่เข้าใจว่าจะทำให้เป็นมาตรฐานได้อย่างไร หลักฐานนี้มาในรูปแบบของอื่น ๆ อีกมากมายที่มาพร้อมกับตัวเลือกการออกแบบที่ไม่ดีเช่นใช้คอลัมน์ varchar สำหรับทุกอย่างหรือมีระเบียบปาเก็ตตี้ของความหมายของตารางและชื่อคอลัมน์ และฉันขอยืนยันกับคุณว่าฉันเห็นฐานข้อมูล "ของจริง" ที่เลวร้ายพอ ๆ กับในบทความ TDWTF
นักพัฒนาผู้ออกแบบก็ไม่ได้ดูแลหรือเป็นอย่างแข็งขันกับการฟื้นฟูบนหลักการ หมายเหตุที่นี่ฉันไม่ได้พูดถึงกรณีที่มีการตัดสินใจอย่างรอบคอบเพื่อไม่ให้เป็นมาตรฐานตามการวิเคราะห์เชิงบริบท แต่แทนที่จะเป็นทีมหรือ บริษัท ที่การทำให้บรรทัดฐานมีความเข้าใจที่มากขึ้นหรือน้อยลง แต่ไม่สนใจหรือหลีกเลี่ยงนิสัย อีกครั้งที่พบบ่อยที่น่าประหลาดใจ
ซอฟต์แวร์ทำ / เคยทำโครงการ Brownfieldแล้ว นักพิถีพิถันหลายคนมองข้ามธุรกิจที่ชอบด้วยกฎหมายนี้อย่างสมบูรณ์มากกว่าเหตุผลทางเทคนิค บางครั้งคุณไม่ได้รับการออกแบบฐานข้อมูลใหม่ตั้งแต่เริ่มต้นคุณต้องเข้าสู่ schema ดั้งเดิมที่มีอยู่และการพยายามทำให้เป็นปกติในจุดนั้นอาจทำให้เกิดความเจ็บปวดมากเกินไป 3NF ไม่ได้ถูกคิดค้นจนกระทั่งปี 1971 และบางระบบ - โดยเฉพาะระบบการเงิน / บัญชี - ทำให้รากของพวกเขากลับมายิ่งกว่านั้นอีก!
ฐานข้อมูลเดิมเป็นมาตรฐานแต่การสะสมของการเปลี่ยนแปลงเล็กน้อยในช่วงระยะเวลานานและ / หรือทีมงานที่มีการกระจายอย่างกว้างขวางได้แนะนำรูปแบบการทำซ้ำที่ละเอียดอ่อนและการละเมิดอื่น ๆ ของรูปแบบปกติใด ๆ กล่าวอีกนัยหนึ่งคือการสูญเสียการฟื้นฟูโดยไม่ได้ตั้งใจและใช้เวลาน้อยเกินไปในการปรับโครงสร้างใหม่
การตัดสินใจทางธุรกิจอย่างรอบคอบนั้นไม่ได้ใช้เวลาในการวิเคราะห์ธุรกิจหรือการออกแบบฐานข้อมูลและเพียงแค่ "ทำให้เสร็จ" นี่มักเป็นเศรษฐกิจที่ผิดพลาดและในที่สุดจะกลายเป็นรูปแบบของหนี้ทางเทคนิคแต่บางครั้งก็เป็นการตัดสินใจที่มีเหตุผลอย่างน้อยที่สุดก็ขึ้นอยู่กับข้อมูลที่เป็นที่รู้จักในเวลา - ตัวอย่างเช่นฐานข้อมูลอาจมีเจตนาเป็นต้นแบบ การส่งเสริมการใช้งานการผลิตเนื่องจากข้อ จำกัด ด้านเวลาหรือการเปลี่ยนแปลงในสภาพแวดล้อมทางธุรกิจ
2. ทำไม / เมื่อใดที่ฐานข้อมูลปกติควรถูกทำให้เป็นมาตรฐาน?
การสนทนานี้มักจะเกิดขึ้นเมื่อฐานข้อมูลเป็นปกติจะเริ่มต้นด้วย ไม่ว่าจะเป็นการแสดงที่ไม่ดีหรือมีการทำซ้ำจำนวนมากในการสอบถาม (เชื่อมต่อ) และทีมรู้สึกถูกหรือผิดที่พวกเขาไปไกลเท่าที่จะทำได้ด้วยการออกแบบในปัจจุบัน เป็นเรื่องสำคัญที่จะต้องทราบว่าการทำให้เป็นมาตรฐานนั้นช่วยปรับปรุงประสิทธิภาพได้เกือบตลอดเวลาและมีหลายทางเลือกในการกำจัดการเข้าร่วมที่มากเกินไปเมื่อการทำให้มาตรฐานกลับคืนสู่สภาพปกติจะทำงานกับคุณได้
สร้างมุมมองที่จัดทำดัชนีซึ่งสรุปพื้นที่ปัญหาที่พบบ่อยที่สุด DBMS ที่ทันสมัยมีความสามารถในการทำให้พวกเขาแทรกหรือปรับปรุงได้ (เช่นINSTEAD OFทริกเกอร์SQL Server ) สิ่งนี้มีค่าใช้จ่ายเล็กน้อยต่อคำสั่ง DML ในตาราง / ดัชนีพื้นฐาน แต่โดยทั่วไปเป็นตัวเลือกแรกที่คุณควรลองเพราะเกือบจะเป็นไปไม่ได้ที่จะพลาดและไม่มีค่าใช้จ่ายในการบำรุงรักษา แน่นอนไม่ใช่ทุกคำถามที่สามารถเปลี่ยนเป็นมุมมองที่จัดทำดัชนี - แบบสอบถามแบบรวมเป็นสิ่งที่ลำบากที่สุด ซึ่งนำเราไปสู่รายการถัดไป ...
สร้างตารางรวมที่มีความผิดปกติที่ทริกเกอร์อัพเดทโดยอัตโนมัติ ตารางเหล่านี้อยู่นอกเหนือไปตารางปกติและรูปแบบชนิดของCQRSรุ่น อีกรุ่นหนึ่งที่ได้รับความนิยมมากในปัจจุบันคือการใช้ pub / sub เพื่ออัปเดตโมเดลเคียวรีซึ่งให้ประโยชน์ของแบบอะซิงโครนัสแม้ว่าจะไม่เหมาะในกรณีที่หายากมากซึ่งข้อมูลไม่สามารถค้างได้
บางครั้งมุมมองที่จัดทำดัชนีเป็นไปไม่ได้อัตราการทำธุรกรรมและปริมาณข้อมูลสูงเกินไปที่จะยอมรับทริกเกอร์ที่มีประสิทธิภาพที่ยอมรับได้และแบบสอบถามจะต้องส่งคืนข้อมูลเรียลไทม์เสมอ สถานการณ์เหล่านี้เป็นของหายาก - ฉันคาดเดาได้ยากว่าพวกเขาอาจนำไปใช้กับสิ่งต่าง ๆ เช่นการซื้อขายความถี่สูงหรือฐานข้อมูลการบังคับใช้กฎหมาย / ข่าวกรอง - แต่พวกเขาสามารถมีอยู่ได้ ในกรณีเหล่านี้คุณไม่มีตัวเลือกจริงๆยกเว้นการทำให้ตารางต้นฉบับผิดปกติ
3. ในสถานการณ์ใดที่เป็นอันตรายหรือไม่จำเป็นที่จะต้องทำให้เป็นมาตรฐานในตอนแรก?
อันที่จริงมีตัวอย่างที่ดีหลายอย่างที่นี่:
ถ้าฐานข้อมูลจะถูกใช้เพียงสำหรับการรายงานการวิเคราะห์ / โดยทั่วไปแล้วนี่หมายความว่ามีฐานข้อมูลปกติเพิ่มเติมที่ใช้สำหรับ OLTP ซึ่งมีการซิงโครไนซ์กับฐานข้อมูลการวิเคราะห์เป็นระยะ ๆ ผ่าน ETL หรือการส่งข้อความ
เมื่อมีการบังคับใช้แบบจำลองที่เป็นมาตรฐานจะต้องมีการวิเคราะห์ที่ซับซ้อนโดยไม่จำเป็นของข้อมูลที่เข้ามา ตัวอย่างนี้อาจเป็นระบบที่ต้องการเก็บหมายเลขโทรศัพท์ที่รวบรวมจากระบบภายนอกหรือฐานข้อมูลต่าง ๆ คุณสามารถทำให้รหัสการโทรและรหัสพื้นที่ผิดปกติได้ แต่คุณต้องพิจารณารูปแบบที่เป็นไปได้ทั้งหมดหมายเลขโทรศัพท์ที่ไม่ถูกต้องหมายเลขโต๊ะเครื่องแป้ง (1-800-GET-STUFF) ทั้งหมดไม่ต้องพูดถึงตำแหน่งที่ตั้งอื่น มักจะมีปัญหามากกว่าค่าใช้จ่ายและหมายเลขโทรศัพท์มักจะถูกผลักลงในฟิลด์เดียวเว้นแต่ว่าคุณมีความต้องการทางธุรกิจเฉพาะสำหรับรหัสพื้นที่ด้วยตัวเอง
เมื่อฐานข้อมูลเชิงสัมพันธ์เป็นหลักเพื่อให้การสนับสนุนการทำธุรกรรมสำหรับฐานข้อมูลเพิ่มเติมที่ไม่ใช่เชิงสัมพันธ์ ตัวอย่างเช่นคุณอาจใช้ฐานข้อมูลเชิงสัมพันธ์เป็นคิวข้อความหรือเพื่อติดตามสถานะของธุรกรรมหรือ saga เมื่อข้อมูลหลักถูกเก็บไว้ใน Redis หรือ MongoDB หรืออะไรก็ตาม กล่าวอีกนัยหนึ่งข้อมูลคือ "ข้อมูลควบคุม" ปกติแล้วจะไม่มีจุดในการทำให้ข้อมูลเป็นปกติซึ่งไม่ใช่ข้อมูลธุรกิจจริงๆ
สถาปัตยกรรมที่มุ่งเน้นบริการที่ใช้ฐานข้อมูลร่วมกัน นี่เป็นบิตแปลก ๆ แต่ใน SOA จริงคุณจะต้องมีข้อมูลซ้ำซ้อนในบางครั้งเนื่องจากบริการไม่ได้รับอนุญาตให้สอบถามข้อมูลของกันและกันโดยตรง หากพวกเขาเกิดขึ้นจะได้รับการแบ่งปันฐานข้อมูลทางกายภาพเดียวกันข้อมูลจะปรากฏที่จะไม่ปกติ - แต่โดยทั่วไปแล้วข้อมูลที่เป็นเจ้าของโดยการบริการของแต่ละคนจะยังคงปกติยกเว้นในกรณีที่เป็นหนึ่งในปัจจัยบรรเทาอื่น ๆ ที่อยู่ในสถานที่ ตัวอย่างเช่นบริการการเรียกเก็บเงินอาจเป็นเจ้าของกิจการบิล แต่บริการบัญชีจำเป็นต้องได้รับและเก็บวันที่เรียกเก็บเงินและจำนวนเงินเพื่อรวมไว้ในรายได้สำหรับปีนั้น
ฉันแน่ใจว่ามีเหตุผลเพิ่มเติมที่ฉันไม่ได้ระบุไว้ สิ่งที่ฉันได้รับในสาระสำคัญคือพวกเขาค่อนข้างเฉพาะและจะค่อนข้างชัดเจนเมื่อพวกเขามาในทางปฏิบัติ ฐานข้อมูล OLAP ควรใช้แบบแผนของสตาร์ดังนั้นควรมีการทำสำเนาซ้ำเป็นต้นหากคุณกำลังทำงานกับแบบจำลองสถาปัตยกรรมที่รู้จักกันดีซึ่งไม่สามารถใช้งานกับการทำให้เป็นมาตรฐานได้ โดยทั่วไปแล้วตัวแบบสถาปัตยกรรมจะมีความสำคัญมากกว่าตัวแบบข้อมูล
และเพื่อตอบคำถามสุดท้าย:
มันเป็นความจริงหรือไม่ที่สถาปนิกและผู้เชี่ยวชาญที่ดีเลือกการออกแบบที่ผิดปกติในขณะที่นักพัฒนาที่ไม่มีประสบการณ์เลือกตรงกันข้าม อะไรคือข้อโต้แย้งในการเริ่มต้นการออกแบบของคุณโดยคำนึงถึงการฟื้นฟูสภาพ
ไม่เสร็จสมบูรณ์และชัดแจ้งที่สุด BS ยังเป็นผู้เชี่ยวชาญที่เลือกการออกแบบตามปกติเสมอ ผู้เชี่ยวชาญไม่เพียง แต่ทำตามมนต์ พวกเขาวิจัยวิเคราะห์อภิปรายชี้แจงและทำซ้ำแล้วเลือกวิธีการใดก็ตามที่เหมาะสมที่สุดสำหรับสถานการณ์เฉพาะของพวกเขา
ฐานข้อมูล 3NF หรือ BCNF มักจะเป็นจุดเริ่มต้นที่ดีสำหรับการวิเคราะห์เพราะมันได้รับการทดลองและพิสูจน์แล้วว่าประสบความสำเร็จในหลายหมื่นโครงการทั่วโลก แต่แล้วอีกครั้งดังนั้น C จึงไม่ได้หมายความว่าเราจะใช้ C ในทุก ๆ โครงการใหม่. สถานการณ์ในโลกแห่งความเป็นจริงอาจต้องมีการดัดแปลงโมเดลหรือการใช้โมเดลอื่นโดยสิ้นเชิง คุณไม่รู้จนกระทั่งคุณอยู่ในสถานการณ์นั้น