Thiết kế cơ sở dữ liệu tốt, số thuộc tính biến số

Question

Tôi đang cố tạo cơ sở dữ liệu chứa danh sách thiết bị. Tất cả các thiết bị sẽ có một số thuộc tính phổ biến (như nhà sản xuất, model #, serial #, vv), sau đó có các thuộc tính khác dành riêng cho một thiết bị nhất định (ví dụ, modem sẽ có quyền truy cập #, trong khi một bảng điều khiển năng lượng mặt trời sẽ có công suất đầu ra). Tôi không chắc chắn làm thế nào để đại diện cho các thuộc tính thay đổi với các nguyên tắc thiết kế cơ sở dữ liệu tốt, tôi đã cố gắng tìm kiếm trên web, nhưng tôi không hoàn toàn chắc chắn những gì để tìm kiếm.

tôi đã đi lên với các giải pháp khả thi sau và những suy nghĩ ban đầu của tôi về họ:

1. Có một bảng lớn với tất cả các thuộc tính càng tốt và chỉ cần đặt rỗng mà nó không được áp dụng. Rõ ràng điều này có một số sai sót.

2. Có bảng riêng cho từng loại thiết bị. Điều này có vẻ như nó có thể là một cơn ác mộng để sử dụng, nếu tôi muốn in một danh sách của tất cả các thiết bị, làm thế nào để tôi biết bảng tra cứu?

3. Có bảng có thuộc tính chung và các bảng khác cho từng loại thiết bị được truy cập bằng khóa ngoài để lưu trữ thuộc tính bổ sung. Tôi có thể có thể làm cho công việc này, nhưng nó sẽ là cồng kềnh và chỉ không cảm thấy giống như một giải pháp rất tốt.

4. Mô hình loại thuộc tính-giá trị. Có vẻ như không phù hợp với những gì tôi muốn làm.

Tôi không có nhiều kinh nghiệm về cơ sở dữ liệu nên tôi đang học ở đây, bất kỳ liên kết nào liên quan đến vấn đề này hoặc "phải đọc" bài viết về thiết kế cơ sở dữ liệu sẽ được đánh giá cao. Cảm ơn!

EDIT: Trước hết, tôi phát hiện ra rằng tôi cần Google "Lập bản đồ thừa kế", điều đó có thể giúp bất kỳ ai khác có câu hỏi tương tự. Để giải quyết vấn đề tôi đã kết thúc bằng cách sử dụng lai # 2 và # 3. Nó thực sự khá dễ dàng, hoạt động tốt, và giải quyết vấn đề thêm các loại thiết bị bổ sung mà không có sự phức tạp của EAV. Cảm ơn tất cả các ý kiến ​​và đề xuất!

Answer 1

Tùy chọn 1, 2 và 3 chia sẻ một lỗ hổng rất nghiêm trọng: bạn phải sửa đổi lược đồ bảng cơ bản khi ai đó mơ ước một thuộc tính mới. Trong trường hợp Lựa chọn 1, vấn đề là phức tạp bởi khả năng một loại thiết bị mới sẽ được giới thiệu. Bạn chắc chắn rằng tập các thuộc tính được cố định cho mọi thời gian?Làm thế nào hạnh phúc bạn sẽ được để mất điện hoặc nói với khách hàng rằng không, bạn không thể có một thuộc tính mới?

Nếu bạn rất có khả năng thực hiện truy vấn thuộc tính chung, bạn có thể thử kết hợp 3 và 4, với dấu gạch ngang 2 được ném vào loại thuộc tính thay vì loại thiết bị, có vẻ dễ bay hơi hơn nhiều. Tùy chọn 4, nếu tôi hiểu chính xác, là một phiên bản biểu mẫu bình thường của tùy chọn 1 giải quyết tất cả các vấn đề vốn có của nó (thưa thớt và giòn).

INVENTORY(id*, model, manufacturer, serial) 
ATTRIBUTE(id*, name, type, description) 
INVENTORY_FACT_STRING(inv_id*, attr_id*, value) 
INVENTORY_FACT_NUMBER(inv_id*, attr_id*, value) 
INVENTORY_FACT_LIST_STRING(inv_id*, attr_id*, ordinal*, value) 

, vv

Answer 2

Khó giải quyết vấn đề đối với bất kỳ cơ sở dữ liệu SQL nào. Không có câu trả lời tuyệt vời cho MySQL.

1) Hoạt động và bạn có thể thêm một số chế độ xem cho các loại thiết bị quan trọng. Nó làm giảm số lượng tham gia và cho phép truy vấn và lập chỉ mục trên mỗi trường.

2) Bạn có thể sử dụng kết hợp tất cả truy vấn trong chế độ xem. PostgreSQL và Informix có thừa kế bảng.

3) Đây thường là lựa chọn triển khai. Một lần nữa, bạn có thể sử dụng các khung nhìn cho các phép nối.

4) PostgreSQL, Informix, Oracle, IBM DB2 và MS SQL Server có hỗ trợ kiểu dữ liệu XML để triển khai các cặp giá trị.

Ở cấp độ cao hơn, bạn có thể phát triển mô hình meta của thiết bị trong XML. Sau đó, bạn có thể sử dụng mô hình này để tạo các truy vấn SQL lược đồ và mã CRUD.

Answer 3

Tôi nghĩ rằng bạn phải đối mặt với một chuẩn hóa dữ liệu thông thường. Bạn cần bàn như:

Items -> Id, Name, Model, Brand Id 
Brands -> Id, Name 
Attribute Names -> id, name 
Attribute Mappings -> Id, Names Id, Items Id, Attribute Description 

Trong trường hợp nếu có nhiều hơn một Attribue, danh sách sau đó trong bảng thuộc tính và liên kết với các sản phẩm Id vv Hãy thử để đưa ra hình thức bình thường hóa 3rd

Database Normalization

Answer 4

Các giải pháp thay thế 1, 2 và 3 được Martin Fowler nêu trong một trong các cuốn sách của ông và trên trang web của ông.

Single Table Inheritance (option 1)

Concrete Table Inheritance (option 2, sort of)

Class Table inheritance (option 3)

sở thích của tôi là lựa chọn 3. Mỗi người đều có vị trí của nó trong chương trình chung của sự vật.

EAV chứa các thuộc tính mới khi đang bay rất tốt. Nhưng khi đến lúc chuyển dữ liệu thành thông tin hữu ích, cơ sở dữ liệu EAV có thể là một cơn ác mộng.

Tôi có câu trả lời dài hơn, mà tôi sẽ đăng theo yêu cầu.