On Tue, Jul 27, 2010 at 22:29, Craig Taverner <[email protected]> wrote: > Mapping property values to a discrete set, and refering to them using > their 'id' is quite reminiscent of a foreign key > in a relational database.
Yes, with a relational database I would create foreign keys and maybe bitmap indexes on columns used for search. But I was thinking about a compression algorithm like these: http://www.ibm.com/developerworks/data/library/techarticle/dm-0605ahuja/index.html > Why not take the next step and make a node for each value, and link > all data nodes to the value nodes? I've thought about using nodes and relationships to index these values, but as you've said, this would generate a big number of relationships. I've 200 properties indexed and the dictionary of encoded values contains 15k entries (many properties have a set of hundreds of possible values). Now I've only 600k nodes but each node has from one to several encoded properties. Considering that mantaining an index is expensive, maybe an acceptable trade-off is to put the dictionary of encoded values in the graph, but create relationships from dictionary entries to nodes only for OpenStreetMap properties used for search. > In cases where very many data nodes link to very few index nodes, > there is another trick I'm fond of, and that is the > composite index I need more informations on the implementation of this composite index :) -- Davide Savazzi _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
