¿Es RavenDB una buena opción para este concepto?

Question

Primero, una advertencia: soy bastante nuevo en los conceptos detrás de las bases de datos de documentos, por lo que esta puede ser una pregunta completamente obvia.

Necesito diseñar un sistema que mantenga un profundo catálogo jerárquico de piezas que componen productos altamente complejos. Detallará los componentes físicos que componen cada parte, y cada parte puede ser componentes de otras partes, hasta el producto final. De esta manera:

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

Widget en este ejemplo podría luego incorporarse como parte debajo de algún otro producto.

Cada producto puede contener decenas de miles a cientos de miles de piezas y, cada tipo de componente tiene propiedades diferentes, no relacionadas que deben mantenerse. Estas propiedades pueden incluir las conexiones entre partes relacionadas.

Tenemos una versión mal diseñada de este sistema en este momento, en SQL Server, como una única tabla plana con aproximadamente 120 columnas y varios millones de registros. Alrededor del 85% de los campos en esta tabla son nulos. Mi trabajo es reemplazar esto con algo más fácil de mantener y eficiente y menos propenso a errores.

Construir esto de manera eficiente en una base de datos relacional significaría la normalización, en este caso, tener una tabla para cada tipo de pieza. Creo que este sería un problema, ya que hay cientos de tipos de piezas y se agregan regularmente nuevos tipos de piezas con sus propias propiedades específicas.

Me gustaría utilizar RavenDB para esto, ya que una base de datos de documentos se adaptaría a la naturaleza dinámica de las piezas, pero no sé si sería una buena opción, o cómo implementaría el sistema en términos de documentos. Los productos en sí son los objetos raíz, pero debido a su tamaño no puedo permitirme almacenar un producto como un documento único.

¿Es RavenDB una buena opción para este concepto? ¿Hay indicadores sobre la mejor manera de representarlo en los documentos?

Answer 1

Erik, si una base de datos de documentos encaja perfectamente en esta situación y qué tipo de estructura sería la mejor depende del tipo de operaciones que desee realizar con estos datos.

Por supuesto que puede utilizar RavenDB persistir sus partes y productos, sino para responder a la pregunta si es una buena opción, tiene que responder a la siguiente pregunta: ¿

• ¿Qué tipo de consultas Qué se necesita?
• ¿Cuál es el rendimiento más importante para su sistema, lee o escribe?
• ¿Se puede vivir con consistencia eventual?
• ¿Puede tomar ventaja de características como mapas/reducir índices?
• etc.

Answer 2

esto parece una muy buena opción para una base de datos relacional:

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

PartRelations 
    - ParentPartId (PK) 
    - ChildPartId (PK) 

Usando ese esquema, se podría construir fácilmente jerarquías masivas de piezas, el almacenamiento de la información de la pieza una sola vez, y luego simplemente almacenar la relación de parte de padre a parte de niño

Se podría añadir aún más el modelo de atributos a este para permitir que sus partes tengan todas las propiedades diferentes

PartAttribute 
    - PartId 
    - Attribute 
    - Value 

atributo, más podría ser desglosado si quería en otra tabla Atributo

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

Luego, en la tabla PartAttribute, puede usar AttributeId en lugar de Attribute. En la práctica, descubrí que simplemente usar una cadena en lugar de una tabla de atributos que los enumera a todos es un poco más fácil de codificar y tan fácil de mantener

Puede usar una base de datos de documentos, pero debido a que las piezas son tan relacionado, no estoy seguro de que sea una buena opción, estoy seguro de que algunas personas podrían estar en desacuerdo conmigo.