วิธีจัดการกับการออกแบบตารางด้วยคอลัมน์ตัวแปร

ฉันมีสถานการณ์การออกแบบตารางและเป็นประเภทที่ไม่ใช่ DBA ต้องการความคิดเห็นที่ปรับขนาดได้มากกว่า

สมมติว่าคุณถูกขอให้บันทึกข้อมูลบ้านในพื้นที่เมืองใหญ่โดยเริ่มจากย่านเล็ก ๆ (บ้าน 200 หลัง) แต่ในที่สุดจะเติบโตเป็นบ้าน 5 แสนหลัง

คุณจะต้องจัดเก็บข้อมูลพื้นฐาน: ID # (# ล็อตที่ไม่ซ้ำกันที่เราสามารถใช้เป็นดัชนีที่ไม่ซ้ำกัน), Addr, City, State, Zip ปรับตารางง่าย ๆ จะจัดการกับมัน

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

สุดท้าย - ในแต่ละปีจำนวนคอลัมน์พิเศษจะเปลี่ยนไป อาจเริ่มต้นด้วย 2 คอลัมน์เพิ่มเติมจากนั้นไปที่ 6 ปีหน้าจากนั้นกลับไปที่ 2

ดังนั้นวิธีหนึ่งในตารางคือพยายามเพิ่มข้อมูลที่กำหนดเองเป็นคอลัมน์ในตารางบ้านเพื่อให้มีเพียงหนึ่งตาราง

แต่ฉันมีสถานการณ์ที่มีคนวางตารางสำหรับสิ่งนี้เช่น:

คอลัมน์ "House Table": ID, Addr, City, State, Zip - ด้วยหนึ่งแถวต่อบ้าน

ID   Addr              City     State  Zip 
-------------------------------------------
1    10 Maple Street   Boston      MA  11203

2    144 South Street  Chelmsford  MA  11304

3    1 Main Avenue     Lowell      MA  11280

คอลัมน์ "ตารางข้อมูลที่กำหนดเอง": ID, ชื่อ, ค่า - พร้อมตารางที่มีลักษณะดังนี้:

ID   Name             Value

1    Last Name        Smith

2    Last Name        Harrison

3    Last Name        Markey

1    Square Footage   1200

2    Square Footage   1930

3    Square Footage 

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

1    Last Name    Smith

2    Last Name    Harrison

3    Last Name    Markey

1    First Name   John

2    First Name   Harry

3    First Name   Jim

ในที่สุดคุณรวม 100,000 แถวบ้านและหนึ่งปีมีข้อมูลเพิ่มเติม 10 ชิ้น; ตารางที่สองในขณะนี้คือข้อมูล 1,000,000 แถวซึ่งหลายแห่งมีข้อมูลซ้ำซ้อน (คำอธิบาย) ความต้องการฐานข้อมูลโดยรวมคือผู้คนจะต้องได้รับข้อมูลแถวบ้าน + ค่าฟิลด์ที่กำหนดเองที่เกี่ยวข้องหลายพันครั้งต่อวัน

ดังนั้นคำถามของฉัน: มันจะดี (หรือน่ากลัว) ฝึกแทน:

A) เค้าโครงตารางบ้านโดยเดาได้สูงสุด # คอลัมน์ที่กำหนดเอง (อาจเรียกว่า "1" ถึง "10") และแทรกค่าที่กำหนดเองเหล่านั้นลงในแถวบ้าน

หรือ

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

ขอบคุณหวังว่ามันจะสมเหตุสมผล!

คุณมีตัวเลือก 4 อย่าง:

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

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

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

ตารางมาตรฐานที่มีคอลัมน์เพิ่มเติมมากมาย - คุณมีฐานข้อมูลเชิงสัมพันธ์คุณไม่สามารถใช้ XML หรือ EAV อย่างใดอย่างหนึ่งและ NoSQL ไม่ใช่ตัวเลือก เพิ่มคอลัมน์พิเศษจำนวนมากของแต่ละประเภท ฉันจะเดา varchar 30 หรือมากกว่า, 30 หรือมากกว่าจำนวนเต็ม, 15 หรือมากกว่าตัวเลข และเมื่อคุณใช้คอลัมน์หาค่าไม่ได้กลับมาใช้มัน และอย่าลบคอลัมน์ด้วย

จากโซลูชันเหล่านี้ทั้งหมดความคิดเห็นของฉันคือคุณจะพบว่าวิธี NoSQL หรือ EAV จะประสบความสำเร็จมากที่สุดด้วยจำนวน refactoring รหัสของคุณและ schema ของคุณน้อยที่สุด

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

เพื่อตอบคำถามของคุณเกี่ยวกับ 2 ตัวเลือกเหล่านั้นดูเหมือนจะไม่ถูกต้องสำหรับฉัน ก) จะล็อคคุณและ B) เป็นงานจำนวนมาก สคีมาปัจจุบันที่คุณอธิบายไม่เลวร้ายเกินไป (ยกเว้นการมีชื่อข้อมูล ("ชื่อ", "ตารางฟุต" ฯลฯ ) เป็นสตริงแทนที่จะเป็น ID ที่อ้างอิงถึงตารางการค้นหา

อย่างไรก็ตามนี่ดูเหมือนว่าฉันจะชอบผู้สมัครที่ดีสำหรับฐานข้อมูล NoSQL ( http://en.wikipedia.org/wiki/NoSQL ) ในขณะที่ฉันไม่เคยทำงานกับฐานข้อมูลดังกล่าวสิ่งที่คุณอธิบายเป็นสถานการณ์ทั่วไปที่แก้ได้

หากจำนวนคอลัมน์ที่กำหนดเองพร้อมกันนั้นมี จำกัด และเป็นที่รู้จัก (เช่นไม่เกิน 10-20 คอลัมน์ที่กำหนดเองสำหรับสตริง, ไม่เกิน x คอลัมน์สำหรับจำนวนเต็ม ฯลฯ )
คุณสามารถใช้ตารางฐานที่มีเขตข้อมูลพิเศษต่อประเภทข้อมูลและแทน การสร้างตารางใหม่ทุกปีสร้างมุมมองสำหรับปีนั้นรวมถึงเฉพาะคอลัมน์ที่กำหนดเองที่เกี่ยวข้องและเปลี่ยนชื่อฟิลด์ทั่วไปเพื่อแสดงเนื้อหาในปีนั้น

House Table:
ID, Addr, City, State, Zip, custom_string1,cs_2,cs_3,custom_integer_1,ci_2,ci_3 ...

create view house_2014 as 
select ID, Addr, City, State, Zip,
custom_string1 as last_name,cs_2 as first_name ...

ปัญหาของวิธีนี้คือคุณไม่มีประวัติ แต่คุณสามารถทำสำเนาได้ง่ายทุกปีก่อนที่จะเปลี่ยนข้อกำหนดของคอลัมน์

create table house_2014_archive as select * from house_2014;
drop house_2014;
create view house_2015 as "select column list for new year";

คุณสามารถระบุสถานการณ์ทั้งหมดที่คุณต้องการจัดเก็บข้อมูลนี้ได้หรือไม่?

หากมีจำนวนคอลัมน์รวมกันจำนวนเล็กน้อยที่อาจนำไปใช้กับตารางได้ให้ลองจำลอง "ตารางฐาน" กับคอลัมน์ทั่วไปที่ gpoing ใช้กับทุกสถานการณ์แล้วสร้างตารางเพิ่มเติม (เพื่อนำมรดกมาใช้บางประเภท สิ่งนี้เรียกว่า subtype / supertype ใน ERD และการออกแบบฐานข้อมูล)

หนึ่งตารางสำหรับแต่ละสถานการณ์ด้วยวิธีนี้อย่างน้อยที่สุดคุณจะรักษาความสะอาดของตารางและคุณจะสามารถหลีกเลี่ยงการเก็บที่อยู่ในคอลัมน์ "นามสกุล" ...

ดูคำถามการออกแบบนี้: /programming/554522/something-like-inheritance-in-database-design