Nhược điểm của bảng có quá nhiều cột

Có một số điều cần xem xét ở đây:

• Danh sách các thuộc tính có thay đổi đáng kể theo thời gian không
• Danh sách các thuộc tính có yêu cầu các thuộc tính tùy chỉnh do người dùng xác định không
• Có các thuộc tính khác nhau cho các trường khác nhau không (tức là nhiều thuộc tính chỉ áp dụng cho một hoặc một vài trường)?

Nếu bất kỳ điều nào trong số này là đúng, bạn có thể nghĩ đến cách tiếp cận cửa hàng thuộc tính như EAV, hstore, json trường, trường xml, v.v. .

Nếu không - nếu bạn có một danh sách các thuộc tính khá tĩnh trong đó hầu hết chúng có ý nghĩa đối với hầu hết các hàng - thì không thực sự có vấn đề gì với việc có chúng dưới dạng 60 cột riêng lẻ. Sẽ dễ dàng hơn khi thêm chỉ mục cho các tập hợp thuộc tính được tìm kiếm phổ biến, bao gồm chỉ mục một phần và chỉ mục tổng hợp, v.v. và các tìm kiếm - đặc biệt là những tìm kiếm cho nhiều thuộc tính khác nhau - sẽ nhiều nhanh hơn.

Xem thêm: Thiết kế cơ sở dữ liệu - tôi nên sử dụng 30 cột hay 1 cột với tất cả dữ liệu ở dạng JSON / XML ?

Ngoài ra còn có một tùy chọn thỏa hiệp có sẵn cho bạn:Một bảng chính cho các chi tiết quan trọng nhất mà bạn tìm kiếm rất nhiều, cùng với các bảng phụ cho các nhóm thuộc tính hợp lý. Nói:

yearly_summary (
    yearly_summary_id serial primary key,
    school_id integer,
    total_students integer,
    ...
) 

cộng với

yearly_student_stats(
    yearly_summary_id integer primary key references yearly_summary(yearly_summy_id) on delete cascade,
    ...
)

v.v ... Khoá chính integer primary key đó cũng là foreign key nghĩa là bạn có mối quan hệ 1:1 (tùy chọn) được thực thi với bảng khác. Cách tiếp cận này có thể hữu ích nếu bạn có một vài nhóm thuộc tính hợp lý mà bạn có thể tập hợp thành các bảng phụ.

Tôi cũng sẽ ngạc nhiên nếu suy nghĩ nhiều hơn một chút không tiết lộ những điều làm có ý nghĩa để bình thường hóa. Bạn có year7_blah không , year8_blah , year9_blah vv cột? Nếu vậy:Ứng cử viên sáng giá cho việc chuẩn hóa.