RavenDB có phù hợp với khái niệm này không?

Question

Đầu tiên, hãy báo trước: Tôi khá mới mẻ với các khái niệm đằng sau cơ sở dữ liệu tài liệu, vì vậy đây có thể là một câu hỏi hoàn toàn rõ ràng.

Tôi cần phải thiết kế một hệ thống duy trì một danh mục phân cấp sâu của các bộ phận tạo nên các sản phẩm có độ phức tạp cao. Nó sẽ chi tiết các thành phần vật lý tạo thành từng phần - và mỗi phần có thể là các thành phần của các bộ phận khác - tất cả các con đường đến sản phẩm cuối cùng. Như thế này:

Widget 
|- Sprocket 
| |- A4 nut 
| |- B15 screw 
| |- Sprocket Backshell 
|- Flange 
| |- A4 washer 
| |- Flange Housing 
|- Widget Assembly 

Widget trong ví dụ này sau đó có thể được kết hợp dưới dạng Phần bên dưới một số Sản phẩm khác.

Mỗi sản phẩm có thể chứa hàng chục nghìn đến hàng trăm nghìn phần và mỗi loại thành phần có các thuộc tính khác nhau, không liên quan phải được duy trì. Các thuộc tính này có thể bao gồm các kết nối giữa các phần liên quan.

Hiện tại, chúng tôi có phiên bản kém được thiết kế của hệ thống này, trong SQL Server, dưới dạng một bảng phẳng đơn với khoảng 120 cột và vài triệu bản ghi. Khoảng 85% các trường trong bảng này là null. Công việc của tôi là thay thế điều này bằng cái gì đó dễ bảo trì hơn và hiệu quả hơn và ít bị lỗi hơn.

Xây dựng điều này một cách hiệu quả trong cơ sở dữ liệu quan hệ có nghĩa là chuẩn hóa - trong trường hợp này, có một bảng cho từng loại phần. Đây sẽ là một vấn đề mà tôi nghi ngờ vì có hàng trăm loại phần, và các loại phần mới với các đặc tính riêng của chúng được bổ sung thường xuyên.

Tôi muốn sử dụng RavenDB cho điều này, vì cơ sở dữ liệu tài liệu sẽ phù hợp với tính chất động của các bộ phận, nhưng tôi không biết nó có phù hợp hay không. về tài liệu. Bản thân các sản phẩm là các đối tượng gốc, nhưng vì kích thước của chúng tôi không thể đủ khả năng để lưu trữ một sản phẩm dưới dạng một tài liệu duy nhất.

RavenDB có phù hợp với khái niệm này không? Có bất kỳ gợi ý về cách tốt nhất để đại diện cho nó trong tài liệu?

Answer 1

Erik, liệu cơ sở dữ liệu tài liệu có phù hợp với tình huống này không và loại cấu trúc nào là tốt nhất tùy thuộc vào loại hoạt động bạn muốn thực hiện trên dữ liệu này.

Bạn chắc chắn có thể sử dụng RavenDB để tồn tại các bộ phận và sản phẩm của bạn, nhưng để trả lời câu hỏi nếu nó là một lựa chọn tốt, bạn phải trả lời những câu dưới đây:

• Những loại truy vấn nào bạn cần?
• Tính năng quan trọng hơn đối với hệ thống của bạn, đọc hoặc viết là gì?
• Bạn có thể sống với sự nhất quán cuối cùng không?
• Bạn có thể tận dụng các tính năng như chỉ mục bản đồ/giảm không?
• v.v.

Answer 2

Điều này có vẻ như một sự phù hợp khá tốt cho một cơ sở dữ liệu quan hệ:

Part 
    - PartId 
    - Name 
    - ...more fields.. 

PartRelations 
    - ParentPartId (PK) 
    - ChildPartId (PK) 

Sử dụng sơ đồ đó, bạn có thể dễ dàng xây dựng hệ thống phân cấp ồ ạt của các bộ phận, lưu trữ các thông tin phần một lần duy nhất, và sau đó chỉ cần lưu trữ các mối quan hệ của phần cha mẹ cho phần con.

Bạn tiếp tục có thể thêm các mô hình thuộc tính này để cho phép bộ phận của bạn để có tất cả các thuộc tính khác nhau

PartAttribute 
    - PartId 
    - Attribute 
    - Value 

Thuộc tính, hơn nữa có thể được chia nhỏ nếu bạn muốn vào một bảng thuộc tính

Attribute 
    - AttributeId 
    - AttributeName 
    - ..datatype?.. (for pretty formatting logic or other..) 

Sau đó trong bảng PartAttribute, bạn có thể sử dụng AttributeId thay vì Attribute. Trong thực tế, tôi đã thấy rằng chỉ cần sử dụng chuỗi thay vì bảng thuộc tính liệt kê tất cả chúng ra dễ dàng hơn để mã hóa và dễ dàng duy trì

Bạn có thể sử dụng cơ sở dữ liệu tài liệu, nhưng vì các phần Vì vậy, liên quan, tôi không chắc chắn đó là một phù hợp tốt, tôi chắc chắn một số người có thể không đồng ý với tôi mặc dù.