Các mẫu / chiến lược thiết kế cho các trường và kiểu dữ liệu tùy chỉnh

12

Có bất kỳ chiến lược hoặc mẫu thiết kế chung nào để thiết kế các ứng dụng có khả năng thêm các trường tùy chỉnh vào các đối tượng dữ liệu hoặc để tạo định nghĩa tùy chỉnh của các đối tượng. Ví dụ: tôi đang nghĩ về các sản phẩm như SalesForce, nơi bạn có thể có các loại thông tin của riêng mình, các khung như Expression Engine và cách nó xử lý các kênh và nhóm trường kênh (Ví dụ) hoặc Cách CMS như wordpress có khả năng thêm các trường vào các loại bài tùy chỉnh.

design-patterns database-design

— GSto
nguồn

6

Bạn có thể thích đọc một số câu trả lời cho câu hỏi này về việc thiết kế cơ sở dữ liệu cho các trường do người dùng xác định

— Rachel

Lưu ý: Oracle đang đi khắp nơi kiện quần của mọi người thực hiện điều này theo một cách cụ thể (theo những gì tôi hiểu, phổ biến). Tôi cũng sẽ xem qua điều đó.

— Steven Evers

6

Martin Fowler đã đưa ra một mô tả hay về cách mô hình hóa các đặc tính động (về cơ bản là những gì bạn đang yêu cầu) trong cuốn sách "Các mẫu phân tích" . Hầu hết các nội dung có sẵn trực tuyến miễn phí dưới dạng các bài viết PDF, cái mà bạn đang tìm kiếm là cái này:

http://martinfowler.com/apsupp/properIES.pdf

— Bác sĩ Brown
nguồn

4

Các EAVmô hình thường được sử dụng cho lược đồ cấu trúc như bạn mô tả.

Nó chịu hiệu suất và khả năng truy vấn các thuộc tính động như vậy theo cách đặc biệt ... và như vậy được nhiều người coi là một mô hình chống.

Các cách tiếp cận khác là sử dụng định dạng động như XML hoặc Json để giữ các thuộc tính đó, có thể với bộ lưu trữ chuyên dụng cho từng thuộc tính để giúp tìm kiếm.

— Oded
nguồn

Tôi cũng đã nghe nói về những người sử dụng cơ sở dữ liệu định hướng tài liệu thay thế cho EAV, nhưng không có kinh nghiệm cá nhân với cách tiếp cận như vậy.

— Thất vọngWithFormsDesigner

@FrustratedWithFormsDesigner - Đó là những gì tôi đã gợi ý, nhưng như chính bạn, không có kinh nghiệm cá nhân.

— Oded

4

Ngoài bảng EAV mà @Oded mô tả, mọi người sử dụng cơ sở dữ liệu nosql cho loại thông tin này. Hãy nhớ rằng không có lý do tại sao ứng dụng của bạn không thể sử dụng cơ sở dữ liệu quan hệ cho các phần có ý nghĩa với mô hình quan hệ và cơ sở dữ liệu nosql cho thông tin không có.

Khả năng thứ ba là thêm một số cột cho các trường được thêm vào của khách hàng (Customerfield1, customerfield2, v.v.) và sau đó để khách hàng xác định ý nghĩa của chúng. Điều này chỉ hoạt động với số lượng trường comnfiguarble của khách hàng mà bạn thêm vào, vì vậy sẽ tốt nếu bạn chỉ mong họ sẽ cần hai hoặc ba nhưng sẽ không hoạt động nếu bạn cần hàng trăm.

— HLGEM
nguồn

1

Bạn sẽ không có ứng dụng đầu tiên có bảng: UDF1, UDF2, UDF3 ... Các đề xuất khác (EVA hoặc NoQuery) tốt hơn nhiều.

Tùy thuộc vào RDBMS ( SQL Server cung cấp điều này ), bạn có thể thoát ra khỏi chuẩn hóa và có một trường chứa dữ liệu ở định dạng XML hoặc chỉ là văn bản thuần túy. Bạn sẽ phải dựa vào mã để quản lý này.

— Jeff
nguồn