Cách xử lý thiết kế bảng với các cột biến

Tôi có một kịch bản thiết kế bảng và là một loại không phải DBA, muốn có ý kiến ​​về khả năng mở rộng hơn.

Giả sử bạn được yêu cầu ghi lại thông tin về các ngôi nhà cho một khu vực tàu điện ngầm, bắt đầu với một khu phố nhỏ (200 ngôi nhà) nhưng cuối cùng tăng lên hơn 5000000 nhà.

Bạn được yêu cầu lưu trữ thông tin cơ sở: ID # (Một số duy nhất # chúng tôi có thể sử dụng làm chỉ mục duy nhất), Addr, City, State, Zip. Tốt, bảng đơn giản sẽ xử lý nó.

Nhưng mỗi năm, bạn sẽ được yêu cầu ghi lại thông tin thêm về tất cả các ngôi nhà - và thông tin gì sẽ thay đổi mỗi năm. Vì vậy, ví dụ, năm đầu tiên, bạn được yêu cầu ghi lại họ của chủ sở hữu và cảnh quay vuông. Năm thứ hai, bạn được yêu cầu giữ tên cuối cùng, nhưng bỏ đoạn phim vuông và thay vào đó bắt đầu thu thập tên của chủ sở hữu.

Cuối cùng - mỗi năm số # cột thêm sẽ thay đổi. Có thể bắt đầu với 2 cột thêm, sau đó chuyển sang 6 cột tiếp theo, sau đó giảm xuống 2 cột.

Vì vậy, một cách tiếp cận bảng là cố gắng thêm thông tin tùy chỉnh dưới dạng cột trong bảng nhà để chỉ có một bảng.

Nhưng tôi có một tình huống mà ai đó đã đặt ra các bảng cho điều này như:

Các cột "Bảng nhà": ID, Addr, City, State, Zip - với một hàng cho mỗi ngôi nhà

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

Các cột "Bảng thông tin tùy chỉnh": ID, Tên, Giá trị - với bảng trông giống như:

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 

Vì vậy, có nhiều hàng cho mỗi bản ghi nhà riêng lẻ. Mỗi năm khi thông tin tùy chọn yêu cầu thay đổi, bảng này được xây dựng lại theo nghĩa đen, vì vậy năm tới nó có thể trông như sau:

1    Last Name    Smith

2    Last Name    Harrison

3    Last Name    Markey

1    First Name   John

2    First Name   Harry

3    First Name   Jim

Cuối cùng, bạn tích lũy được 100.000 hàng nhà VÀ một năm có thêm 10 thông tin; bảng thứ hai bây giờ là 1.000.000 hàng thông tin, nhiều trong số đó có thông tin (mô tả) dư thừa. Các yêu cầu cơ sở dữ liệu nói chung là mọi người sẽ cần lấy thông tin hàng nhà + các giá trị trường tùy chỉnh được liên kết hàng nghìn lần mỗi ngày.

Vì vậy, câu hỏi của tôi: nó sẽ là thực hành xấu (hoặc khủng khiếp) để thay thế:

A) Bố trí bảng nhà với đoán tối đa # cột tùy chỉnh (được gọi là "1" đến "10") và chèn các giá trị tùy chỉnh đó ngay trong các hàng nhà

HOẶC LÀ

B) Lưu trữ thông tin tùy chỉnh trong bảng nhà, nhưng mỗi năm khi các yêu cầu thay đổi, hãy xây dựng lại bảng nhà chỉ với # cột cần thiết cho thông tin tùy chỉnh, với ý tưởng rằng các yêu cầu có thể bị hỏng và bạn không bao giờ biết tối đa bao nhiêu lĩnh vực tùy chọn có thể được yêu cầu?

Cảm ơn, hy vọng điều này có ý nghĩa!

Bạn có khá nhiều 4 sự lựa chọn:

NoQuery - định nghĩa Mỗi bản ghi được lưu trữ dưới dạng một tập hợp các cặp Khóa / Giá trị. Nó rất linh hoạt và nhanh chóng. Không phải tất cả các nhà văn báo cáo ra khỏi đó hỗ trợ phong cách lưu trữ này. Có rất nhiều ví dụ về triển khai cơ sở dữ liệu của NoQuery. Một thứ dường như phổ biến nhất hiện nay, là MongoDB.

EAV - định nghĩa Đây là nơi bạn xoay toàn bộ bảng hoặc một phần (trong bảng khác) về phía nó. Đây là một lựa chọn tốt nếu bạn đã có một cơ sở dữ liệu quan hệ trong nhà mà bạn không thể di chuyển dễ dàng. Ví dụ về bảng thông tin tùy chỉnh mà bạn đã cung cấp là một ví dụ hay về bảng EAV.

Các bảng tiêu chuẩn với các cột XML - Hãy nghĩ về điều này khi NoQuery đáp ứng các bảng quan hệ. Dữ liệu được lưu trữ trong một cột XML có thể là bất kỳ định dạng nào mà XML hỗ trợ, bao gồm nhiều dữ liệu phụ tương quan. Đối với các cột mà bạn biết sẽ là các cột "thông thường", chúng có thể được xây dựng thành loại cột thích hợp để lưu trữ dữ liệu (LastName, Địa chỉ, Thành phố, Bang, v.v.).

Các bảng tiêu chuẩn có nhiều cột bổ sung - Bạn có cơ sở dữ liệu quan hệ, bạn không thể sử dụng XML hoặc EAV và NoQuery không phải là một tùy chọn. Thêm nhiều cột thêm của từng loại. Tôi sẽ đoán 30 hoặc nhiều varchar, 30 số nguyên trở lên, 15 số trở lên. Và một khi bạn sử dụng một cột cho một giá trị, không sử dụng lại nó . Và đừng xóa cột .

Trong tất cả các giải pháp này, ý kiến ​​của riêng tôi là bạn sẽ thấy cách tiếp cận NoQuery hoặc EAV là thành công nhất với số lượng ít nhất là tái cấu trúc mã và lược đồ của bạn.

Bạn sẽ có một tình huống trong đó bạn thu thập dữ liệu một năm chứ không phải tiếp theo và sau đó thu thập lại dữ liệu đó sau đó. Cố gắng để có được dữ liệu cũ hơn được cập nhật với thông tin chính xác là vấn đề và tốn kém. Lưu trữ là không.

Để trả lời câu hỏi của bạn về 2 lựa chọn đó, dường như không đúng với tôi. A) sẽ khóa bạn trong và B) là rất nhiều công việc. Lược đồ hiện tại bạn mô tả không quá tệ (ngoại trừ việc có tên thông tin ("tên đầu tiên", "chân vuông", v.v.) dưới dạng chuỗi thay vì ID được tham chiếu đến bảng tra cứu.

Tuy nhiên, điều này đối với tôi giống như một ứng cử viên tốt cho cơ sở dữ liệu NoQuery ( http://en.wikipedia.org/wiki/NoQuery ). Mặc dù tôi chưa bao giờ làm việc với cơ sở dữ liệu như vậy, nhưng những gì bạn mô tả là một kịch bản điển hình mà điều này giải quyết.

Nếu số lượng cột tùy chỉnh đồng thời là hữu hạn và các giới hạn được biết đến (ví dụ: không quá 10-20 cột Tùy chỉnh cho Chuỗi, không quá x cột cho số nguyên, v.v.)
Bạn có thể sử dụng bảng cơ sở với các trường bổ sung cho mỗi kiểu dữ liệu và thay vào đó xây dựng lại bảng mỗi năm tạo ra một khung nhìn cho năm đó chỉ bao gồm các cột tùy chỉnh có liên quan và đổi tên các trường chung để phản ánh nội dung cho năm đó.

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 ...

Vấn đề với cách tiếp cận này là, bạn không có lịch sử nhưng bạn có thể dễ dàng tạo một bản sao mỗi năm trước khi thay đổi các yêu cầu cột.

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

Bạn có thể liệt kê tất cả các kịch bản mà bạn muốn lưu trữ dữ liệu này không?

nếu có một số kết hợp cột hữu hạn có thể được áp dụng cho bảng, thì hãy thử mô hình hóa "bảng cơ sở" với các cột phổ biến đang áp dụng cho tất cả các kịch bản, sau đó tạo thêm bảng (để thực hiện một số kiểu thừa kế; cái này được gọi là subtype / supertype trong ERD và thiết kế cơ sở dữ liệu.)

một bảng cho mỗi kịch bản, theo cách này ít nhất bạn sẽ giữ các bảng sạch sẽ và bạn sẽ có thể tránh việc lưu địa chỉ đường phố trong cột "họ"

hãy xem câu hỏi thiết kế này: /programming/554522/sthing-like-inherribution-in-database-design