2012-04-20 27 views
10

Estoy jugando con neo4j, y me preguntaba, ¿es común tener una propiedad type en los nodos que especifican qué tipo de nodo es? Intenté buscar esta práctica y he visto a algunas personas usar name con un propósito como este, pero me preguntaba si se consideraba una buena práctica o si los índices serían el método más práctico.Tipo de propiedad del nodo Neo4j

Un ejemplo sería un nodo "Usuario", que tendría el tipo: user, de esta manera si el índice fuera incorrecto, podría hacer un escaneo de todos los nodos y buscar tipos de user.

Respuesta

7

Cierto, depende de su caso de uso. Si agrega una propiedad de tipo y luego desea buscar a todos los usuarios, entonces tiene problemas potenciales ya que debe examinar esa propiedad en cada nodo para llegar a los usuarios. En ese caso, el índice probablemente sería mejor, pero no en los casos en que necesite consultar a todos los usuarios con condiciones y relaciones no disponibles en el índice (a menos que, por supuesto, su índice sea la fuente del "inicio"). Si tiene gráficos como el mío, donde un tipo de relación implica dos tipos de nodos diferentes, como A- (sabe) - (B) y A o B puede ser un usuario o un cliente, entonces no funciona.

Por lo tanto, su caso de uso es realmente importante: es fácil modelar gráficamente los gráficos, pero es importante "ajustarlo" según su patrón de uso.

4

En mi humilde opinión no debería tener que poner una propiedad de tipo en el nodo. En cambio, una forma común de referenciar todos los nodos de un "tipo" específico es conectar todos los nodos de usuario a un nodo llamado "Usuarios". De esta manera, comenzando en el nodo Usuarios, puede encontrar fácilmente todos los nodos de usuario. El nodo "Usuarios" puede indexarse ​​para que pueda encontrarlo fácilmente o puede conectarse al nodo de referencia.

+5

El único problema con esto es que si usted tiene un gran número de usuarios, podrás comenzar a golpear la pena supernodo. Lo hago ahora en neo4django (https://github.com/scholrly/neo4django) y estoy considerando cambiar a un enfoque de relación/índice hirdo. –

+1

He visto este modelo, supongo que me preocupaba que si el índice/relación se rompía por algún motivo, el tipo de nodo se pierde, pero como señaló @MattLuongo, podemos inferir el uso de ciertos atributos. – Nicholas

2

Creo que realmente depende de usted. A algunas personas les gustan los atributos de tipo indexados, pero creo que son más útiles cuando tienes otros atributos indexados para reducir el número de visitas al índice (por ejemplo, buscar a todos los usuarios mayores de 21 años).

Dicho esto, como señala @Luanne, la mayoría de nosotros trata de resolver el problema primero en gráfico. Otra forma de hacerlo (y la forma más natural, en mi opinión) es utilizar el tipo de relación para inferir un tipo de nodo práctico, es decir, "A - (sabe) -> B", por lo que A debe ser un usuario u otro Lo que puede "saber", y B debe ser otro usuario, un tema u otro objeto que pueda "conocerse".

2

Para las API de cliente, modelar el tipo de elemento como una propiedad facilita la instancia del objeto de dominio correcto en el código del lado del cliente, por lo que siempre incluyo una propiedad de tipo en cada nodo/vértice.

El nombre var "tipo" se usa comúnmente para esto, pero en algunos idiomas como Python, "tipo" es una palabra reservada, entonces uso "tipo_de_elemento" en Bombillas (http://bulbflow.com/quickstart/#models).

Esto no es necesario para bordes/relaciones porque ya contienen un tipo (la etiqueta): tenga en cuenta que Neo4j también usa la palabra clave "tipo" en lugar de la etiqueta para las relaciones.

2

Yo diría que es una práctica común. A modo de ejemplo, así es exactamente como Spring Data Neo4j sabe qué tipo de entidad es un determinado nodo. Cada nodo tiene la propiedad "tipo" que contiene el nombre de clase calificado de la entidad. Estas propiedades se indexan automáticamente en el índice "tipos", por lo que los nodos se pueden buscar muy rápido. Podría implementar su caso de uso exactamente así.

9

Labels se han agregado a neo4j 2.0. Arreglan este problema

Puede crear nodos con etiquetas:

CREATE (me:American {name: "Emil"}) RETURN me; 

Se puede sincronizar en etiquetas:

MATCH (n:American) 
WHERE n.name = 'Emil' 
RETURN n 

Se puede establecer cualquier número de etiquetas en un nodo:

MATCH (n) 
WHERE n.name='Emil' 
SET n :Swedish:Bossman 
RETURN n 

Usted puede eliminar cualquier cantidad de etiquetas en un nodo:

MATCH (n { name: 'Emil' }) 
REMOVE n:Swedish 

Etc ...

Cuestiones relacionadas