2011-01-06 16 views
7

¿Cuál es el patrón aceptado para manejar relaciones de muchos a muchos en un diseño de base de datos de documentos?Nosql many-to-many

Respuesta

3

La forma en que quiera modelar el muchos-a-muchos dependerá del tipo de consultas que quiera hacer, cómo quiera actualizar los datos, etc. ... Digamos que tenemos focos relacionados con los bares de muchos para mucha moda

Se podría modelar un foo como

{ 
    'bars': ['bar1', 'bar2', 'bar3'] 
} 

y modelar una barra como

{ 
    'foos': ['foo_x', 'foo_y', 'foo_z'] 
} 

O usted podría modelar el gráfico o las relaciones entre foo y bar documentos individuales a sí mismos

{ 
    from: 'foo1', 
    to: 'bar1' 
} 

{ 
    from: 'foo1', 
    to: 'bar2' 
} 

{ 
    from: 'foo2', 
    to: 'bar3 
} 

{ 
    from 'foo3', 
    to: 'bar3' 
} 

También hay muchas otras formas. La forma en que desee hacerlo dependerá de las preguntas que desee formular, las operaciones que desea respaldar, lo que quiere que sea eficiente y la indexación disponible en la base de datos.

2

Suponiendo que estamos hablando de casos donde una relación es realmente necesaria en lugar de las que solo existen porque SQL maneja las relaciones mejor que los objetos complejos, el diseño es similar al estándar para SQL: dos relaciones de uno a muchos.

La diferencia clave es que tiene campos multivalores, por lo que en lugar de un tercer documento/tabla que registra conexiones únicas como un par de identificadores, tiene una lista de identificadores en cada documento.

Si se encuentra con casos en los que la lista es demasiado larga, es probable que esté mirando algo que se manejaría mejor mediante la indexación de búsquedas que una relación.

+0

él hablando de documentación –

+0

no, eso es un "documento de base de datos". Una "base de datos de documentos" es algo así como http://www.mongodb.org/ –