Cách lưu trữ dữ liệu với số lượng thuộc tính động trong cơ sở dữ liệu

Question

Tôi có một số đối tượng khác nhau với số thuộc tính khác nhau. Cho đến bây giờ, tôi đã lưu dữ liệu trong các tệp XML dễ dàng cho phép thay đổi số lượng thuộc tính. Nhưng tôi đang cố gắng chuyển nó vào cơ sở dữ liệu.

Cách ưa thích của bạn để lưu trữ dữ liệu này là gì?

Một vài chiến lược tôi đã xác định được cho đến nay:

• Có một trường duy nhất có tên là "thuộc tính" trong bảng của đối tượng và lưu trữ dữ liệu tuần tự hoặc json'ed trong đó.
• Lưu trữ dữ liệu trong hai bảng (đối tượng, thuộc tính) và sử dụng một phần ba để lưu các mối quan hệ, làm cho nó thành một mối quan hệ n: m thực. Giải pháp rất sạch sẽ, nhưng có thể rất tốn kém để lấy toàn bộ đối tượng và tất cả các thuộc tính của nó
• Xác định các thuộc tính mà tất cả các đối tượng có điểm chung và tạo trường cho các đối tượng này vào bảng của đối tượng. Lưu trữ các thuộc tính còn lại dưới dạng dữ liệu tuần tự trong một trường khác. Điều này có lợi thế so với chiến lược đầu tiên, giúp việc tìm kiếm dễ dàng hơn.

Bất kỳ ý tưởng nào?

Answer 1

Nếu bạn bao giờ kế hoạch tìm kiếm attribtes cụ thể, đó là một ý tưởng tồi để tuần tự hóa chúng thành một cột duy nhất, vì bạn sẽ phải sử dụng các hàm mỗi hàng để lấy thông tin ra - điều này không bao giờ được cân tốt.

Tôi sẽ chọn lựa lựa chọn thứ hai của bạn. Có một danh sách các thuộc tính trong một bảng thuộc tính, các đối tượng trong bảng riêng của chúng và một bảng mối quan hệ nhiều-nhiều được gọi là các thuộc tính đối tượng.

Ví dụ:

objects: 
    object_id integer 
    object_name varchar(20) 
    primary key (object_id) 
attributes: 
    attr_id  integer 
    attr_name varchar(20) 
    primary key (attr_id) 
object_attributes: 
    object_id integer references (objects.object_id) 
    attr_id  integer references (attributes.attr_id) 
    primary key (object_id,attr_id) 

mối quan tâm của bạn về hiệu suất được ghi nhận, nhưng trong kinh nghiệm của tôi, nó luôn luôn tốn kém hơn để chia một cột hơn để kết hợp nhiều cột. Nếu nó chỉ ra rằng có vấn đề hiệu suất, nó hoàn toàn chấp nhận được để phá vỡ 3NF vì lý do hiệu suất.

Trong trường hợp đó, tôi sẽ lưu trữ theo cách tương tự nhưng cũng có cột có dữ liệu được tuần tự hóa thô. Miễn là bạn sử dụng trình kích hoạt chèn/cập nhật để giữ cho dữ liệu cột và kết hợp được đồng bộ hóa, bạn sẽ không gặp bất kỳ sự cố nào. Nhưng bạn không nên lo lắng về điều đó cho đến khi một vấn đề thực sự bề mặt.

Bằng cách sử dụng các trình kích hoạt đó, bạn sẽ giảm thiểu công việc cần thiết chỉ khi dữ liệu thay đổi. Bằng cách cố gắng trích xuất thông tin cột phụ, bạn thực hiện công việc không cần thiết trên mọi lựa chọn.

Answer 2

có vẻ như bạn cần một cái gì đó liếm couchdb, không phải là RDBMS.

Answer 3

Một biến thể của giải pháp 2ngày của bạn chỉ là hai bảng (giả sử tất cả các thuộc tính của một loại duy nhất):

T1: | cột dữ liệu Object | object_id |

T2: | Id đối tượng | attribute_name | giá trị thuộc tính | (chỉ mục duy nhất trên 2 cột đầu tiên)

Điều này thậm chí còn hiệu quả hơn khi được kết hợp với giải pháp thứ 3, ví dụ: tất cả các trường phổ biến đều đi vào T1.

Sstuffing> 1 thuộc tính vào blob cùng là không khuyến khích - bạn không thể lọc theo thuộc tính, bạn có thể không có hiệu quả cập nhật chúng

Answer 4

nếu bạn định chỉnh sửa/thao tác/xóa thuộc tính ở thời điểm sau này, hãy thực hiện đúng n: m (tùy chọn thứ hai) sẽ là thứ tôi truy cập. (Hoặc cố gắng làm cho nó 2 bảng mà cùng một thuộc tính lặp đi lặp lại.Nhưng kích thước dữ liệu sẽ cao)

Nếu bạn không giao dịch với các thuộc tính (chỉ chụp và hiển thị dữ liệu) thì bạn có thể tiếp tục và lưu trữ trong một trường với một số dấu phân cách (Hãy chắc chắn rằng dấu tách sẽ không xuất hiện trong giá trị thuộc tính)

Answer 5

Nếu bạn đang sử dụng một db quan hệ, thì tôi nghĩ bạn đã làm tốt việc liệt kê các tùy chọn. Họ từng có ưu và khuyết điểm của họ. Bạn đang ở vị trí tốt nhất để quyết định điều gì làm việc tốt nhất cho hoàn cảnh của bạn.

Cách tiếp cận được tuần tự hóa có thể là nhanh nhất (tùy thuộc vào mã của bạn để hủy tuần tự hóa), nhưng điều đó có nghĩa là bạn sẽ không thể truy vấn dữ liệu bằng SQL. Nếu bạn nói rằng bạn không cần phải truy vấn dữ liệu với SQL, thì tôi đồng ý với @ longneck, có lẽ bạn nên sử dụng một db kiểu khóa/giá trị thay vì một db quan hệ.

EDIT - đọc thêm nhận xét của bạn, TẠI SAO bạn chuyển sang db nếu tốc độ là mối quan tâm chính của bạn. BAD về triển khai XML hiện tại của bạn là gì?

Answer 6

tôi đã sử dụng để thực hiện this scheme:

t_class (id RAW(16), parent RAW(16)) -- holds class hierachy. 
t_property (class RAW(16), property VARCHAR) -- holds class members. 
t_declaration (id RAW(16), class RAW(16)) -- hold GUIDs and types of all class instances 
t_instance (id RAW(16), class RAW(16), property VARCHAR2(100), textvalue VARCHAR2(200), intvalue INT, doublevalue DOUBLE, datevalue DATE) -- holds 'common' properties 

t_class1 (id RAW(16), amount DOUBLE, source RAW(16), destination RAW(16)) -- holds 'fast' properties for class1. 
t_class2 (id RAW(16), comment VARCHAR2(200)) -- holds 'fast' properties for class2 
--- etc. 

RAW(16) là nơi Oracle giữ GUID s

Nếu bạn muốn chọn tất cả các thuộc tính cho một đối tượng, bạn phát hành:

SELECT i.* 
FROM (
     SELECT id 
     FROM t_class 
     START WITH 
       id = (SELECT class FROM t_declaration WHERE id = :object_id) 
     CONNECT BY 
       parent = PRIOR id 
     ) c 
JOIN property p 
ON  p.class = c.id 
LEFT JOIN 
     t_instance i 
ON  i.id = :object_id 
     AND i.class = p.class 
     AND i.property = p.property 

t_property giữ nội dung bạn thường không tìm kiếm (như, mô tả văn bản, v.v.)

Thuộc tính nhanh là các bảng thông thường bạn có trong cơ sở dữ liệu, để làm cho các truy vấn hiệu quả. Chúng giữ giá trị chỉ cho các trường hợp của một lớp nhất định hoặc con cháu của nó. Điều này là để tránh tham gia thêm.

Bạn không phải sử dụng bảng nhanh và giới hạn tất cả dữ liệu của mình vào bốn bảng này.

Answer 7

Hãy để tôi nói một cách cụ thể những gì DVK đang nói.

giá trị Giả sử là của cùng một loại bảng sẽ trông giống như (chúc may mắn, tôi cảm thấy bạn sẽ cần đến nó):

 
dynamic_attribute_table 
------------------------ 
id   NUMBER 
key  VARCHAR 
value  SOMETYPE? 

dụ (xe ô tô):

 
|id| key | value | 
--------------------------- 
| 1|'Make' |'Ford'  | 
| 1|'Model' |'Edge'  | 
| 1|'Color' |'Blue'  | 
| 2|'Make' |'Chevrolet'| 
| 2|'Model' |'Malibu' | 
| 2|'MaxSpeed'|'110mph' | 

Vì vậy ,
thực thể 1 = {('Làm', 'Ford'), ('Mẫu', 'Cạnh'), ('Màu', 'Xanh')}
và,
pháp nhân 2 = {('Tạo ',' Chevrolet '), (' Mẫu ',' Malibu '), (' MaxSpeed ​​',' 110mph ')}.