การออกแบบฐานข้อมูล: ตารางใหม่กับคอลัมน์ใหม่

(นี่แนะนำให้เป็น repost ที่นี่จาก StackOverflow)

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

กล่าวอีกนัยหนึ่งเนื่องจากจะมีคอลัมน์ที่ไม่ได้ใช้จำนวนมากสำหรับองค์ประกอบข้อมูลใหม่เหล่านั้นดูเหมือนว่าจะเหมาะกว่าสำหรับตารางใหม่ใช่หรือไม่

ตารางแรกคือบันทึกการดูหน้าเว็บ (ปัจจุบันมีจำนวน 2 ล้านระเบียน)

- รหัส
- ที่อยู่ IP
- ดูครั้ง
- ประทับเวลาที่ _ สร้าง
- วันที่

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

ฟิลด์เพิ่มเติมสำหรับจุดติดตามต้นทาง (เช่นแหล่งที่มาของการวิเคราะห์ของ Google / สื่อ / แคมเปญ)

ไม่ใช่ทุกครั้งที่มีข้อมูล ฉันจะสมมติว่าประมาณ 10% ของแถวจะมีข้อมูล (เนื่องจากโดยปกติแล้วจะมีการเชื่อมโยงกับการเข้าชมครั้งแรกเท่านั้น)

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

ขอบคุณความคิดเห็น - สามารถเพิ่มมากขึ้นถ้าจำเป็น

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

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

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

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

โดยส่วนตัวฉันเอนไปทางเพิ่มคอลัมน์ในตารางที่มีอยู่ ตารางใหม่ไม่ได้ซื้ออะไรให้คุณเลย:

• คุณไม่ประหยัดพื้นที่มากนักเพราะค่า NULL ในตารางดั้งเดิมไม่ใช้พื้นที่ใด ๆ และตารางใหม่ต้องการตัวระบุบางประเภทที่ชดเชยการประหยัดได้
• ข้อความค้นหาของคุณซับซ้อนมากขึ้น ... where newcolumn is not nullกลายเป็นleft outer join

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

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

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

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