2012-10-03 54 views

Respuesta

10

Al igual que con un RDBMS, dependerá de su dominio y los requisitos de consulta de datos.

¿Su aplicación requiere acceso regular a todas las versiones del objeto o, por lo general, solo a la más reciente, con las versiones anteriores disponibles a través de la actual? Un ejemplo de esto podría ser páginas en Wikipedia. Como en el ejemplo, supongamos que tenemos una página que se encuentra en la versión 3. Entonces, podríamos modelar esto de la siguiente manera:

(pages)-[:PAGE]->(V3)-[:PREV]->(V2)-[:PREV]->(V1) 
^   ^
    |    | 
category  current 
    node  version of page 

Aquí, sólo la versión actual se puede ver a formar parte de la estructura principal, pero es posible que deseamos permitir que todas las versiones formen parte de esa estructura. En este caso, se puede utilizar las propiedades de relación para indicar la versión y tienen todas las versiones de enlace de página de la categoría de nodo:

(V1) 
    ^
    | 
[:PAGE(v=1)] 
    | 
(pages)-[:PAGE(v=2)]->(V2) 
    | 
[:PAGE(v=3)] 
    | 
    v 
    (V3) 

Aquí, se puede recorrer de inmediato a una versión particular de la página simplemente especificando la versión en cuál estás interesado

Una tercera opción podría ser que desee que todas las versiones anteriores estén completamente separadas de la estructura principal. Para esto, puede usar varios nodos de categoría, uno para (current_pages) y otro para (old_pages). Como cada página es reemplazada por una nueva versión, se desvincula de la categoría anterior y en su lugar se vincula a la última. Esto formaría más un tipo de sistema de "archivo" en el que las versiones anteriores podrían incluso moverse a una instancia de base de datos separada.

¡Así que tienes estas tres opciones, además de más de las que no he pensado! Neo4j te permite una gran flexibilidad con este tipo de diseño y no hay absolutamente ninguna respuesta "correcta". Sin embargo, si ninguno de estos te inspira, publica un poco más de información sobre tu dominio para que la respuesta se pueda adaptar más a tus necesidades.

Saludos, Nige

+0

Gracias, eso me puso en el camino correcto. Creo que mezclaré los dos enfoques porque para algunos tipos de acceso, siempre necesito la versión actual (es decir, crearé un tipo de relación '[: CURRENT]' para acelerar eso) pero para otros, necesito consultar una versión específica, así que agregaré una propiedad de versión a la relación. –

+0

@ AaronDigulla Quiero construir un escenario similar. Tengo dos preguntas: 1) supongamos que quiero almacenar algún nodo versionado de un 'Coche' y que tengo un índice colocado en el campo' carId' (UUID). ¿No es un problema terminar con 3 'Car' versionados, teniendo exactamente el mismo campo indexado (conflicto potencial con una consulta como" Retrieve the Car 32 "?)? 2) Con su solución '[: CURRENT]', me imagino que en cada nueva versión, debe romper la relación anterior '[: CURRENT]' para apuntar a la nueva 'Car'version, y esta apuntando con otra' [: PREVIOUS] 'relación en el' Coche' anterior? – Mik378

+1

Para su primera pregunta, consideraría hacer que el UUID represente un elemento inmutable, es decir, una combinación de automóvil + versión.Cada revisión crearía entonces un nuevo UUID y estos podrían ser encadenados para representar el historial de versiones. Para su segunda pregunta: sí, las relaciones deberían romperse y reconstruirse para cada nueva versión que aparezca (de manera similar a insertar un elemento en una lista vinculada). –

1

También puede acercarse a ella desde el otro lado:

(pages)-[:VERSION]->(V1)-[:VERSION]->(V2)-[:VERSION]->(V3) 
^            ^
    |             | 
category           current 
    node           version of page 

ventaja: cuando se crea una nueva versión, que acaba de añadir al final de la cadena, sin necesita "insertarlo" entre la (página) y la versión actual.

desventaja: no puede tirar las versiones antiguas, a menos que reconstruya la cadena. Pero esta probablemente no sea una operación frecuente.

Cuestiones relacionadas