Hi, I like your discussion and I have something to add: The most important question when building a model (be it table schema or graph schema) is what do you want to do with it? What answers should I provide?
If you take the categories in graph database a step further it will not store the properties of each product as simple property on the node but you will have a Relation between the node representing the Product to node representing the Attribute and on the relation you will store the actual property value. This way you can answer question like which attribute are set to each product, which product also have this attribute and more using simple travers over the graph. This is the way I think the model can be<http://img98.imageshack.us/i/shopcategorieserd.png/> I hope it helps, Ido On Sat, Dec 25, 2010 at 12:44 PM, Anders Nawroth <[email protected]>wrote: > Hi! > > > "What can't be expressed nicely in the ER-Diagram are the attribute > > values, as the actual names of those attributes are defined as data > > elsewhere in the model. This mix of metadata and data may be a problem > > when using other underlying data models, but for a graph database, > > this is actually how it's supposed to be used." > > > > Are you saying that you should generally store attribute data > > individually in separate nodes rather than storing the data as node > > properties? > > No, the model has two levels. It stores metadata like if an attribute is > mandatory and it's value range in separate nodes/relationships. For > example, the metadata may define that all TV sets must have a screen > size. The actual values are then stored directly on the nodes. > > So if we look at the bottom of the ER diagram: > > https://github.com/neo4j-examples/java-shop-categories/raw/master/src/main/model/shop-categories-erd.png > the Product would normally have its attributes defined, and in this case > we put [AttributeValues] there instead, as the attribute names (keys) > are not known. > > By traversing from the node of a product, we can determine what > attributes it can have, what attributes it must have and so on. > > The point is that it's quite easy to have both flexibility and full type > safety when using a graph data model. Both data and metadata can be > stored in the same manner, and be directly connected to each other. > > Does this make sense to you? > > > /anders > > > > > > For example, here is a blog entry with its data contained in one node, > > using the node-property key/value pairs: > > > > entry = graphdb.node( > > Title="Some Title", > > Summary="", > > Body="bla bla bla", > > langauge="US", > > Created=2010-12-24, > > Published=2010-12-24, > > Revised=2010-12-24) > > > > Alternatively, you could set it up so that the attributes in separate > nodes: > > > > attribute_subref_node = Subreference.Node.ATTRIBUTE_ROOT(graphdb) > > attribute_subref_node.ATTRIBUTE_TYPE(title_node) > > attribute_subref_node.ATTRIBUTE_TYPE(summary_node) > > attribute_subref_node.ATTRIBUTE_TYPE(body_node) > > attribute_subref_node.ATTRIBUTE_TYPE(language_node) > > attribute_subref_node.ATTRIBUTE_TYPE(published_date_node) > > attribute_subref_node.ATTRIBUTE_TYPE(revision_date_node) > > > > > > When should you choose one way over the other? > > > > Thanks. > > > > James > > _______________________________________________ > > Neo4j mailing list > > [email protected] > > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
