Am 27.06.2011 15:57, schrieb Peter Hunsberger: > On Mon, Jun 27, 2011 at 7:17 AM, Stefan Zapf<ste...@nerdocracy.org> wrote: >> "In relational database design, there are normal forms to guide the >> design process. Are there similar prinicples that apply to the design of >> graph databases like neo4j? >> > I haven't done anything with Neo4J yet, but in the past I implemented > a generalized graph management application (proprietary to the company > that I did it for), so this answer may not be 100% accurate for > Neo4j... My experience has been that you still need to do your > logical modelling almost exactly as you would for any other database. > In fact, there is no reason a good ER tool can't be used to map the > major entities and their relationships. You also want to continue to > look for normalization and abstraction patterns. In the end, part of > the decision on which physical model (graph / relational) to use comes > down to many issues that are not necessarily directly related to the > logical model; read / write ratios, total data volumes, concurrent > access etc., but the logical model may be the same in both cases. > > Peter Hunsberger > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user Hi Peter,
these really good points. It took me a while to grasp what you are saying. If we look at a graph from the perspective of normal forms, the flexibility in creating new nodes and relationship combined with the schemaless design, would require less hassle than in SQL databases to achieve higher normal forms. I'm not sure whether the theoretical reasons for the increased speed and integrity of normal forms would apply to graphs as well. My math skills in this area are pretty limited, but maybe I'll try to learn some more and do some tests. One reason for us choosing neo4j was that we simply don't know yet what relationships will exist between the entities. These will emerge through user-interaction and from our ideas on how to use the data. The logical model will be altered by the interaction with the system and doing this I find pretty painful in SQL databases. So although we could model and re-model the logical layer in a SQL database, it's easier in a graph database. One could say it's more an administrtative reason. So the idea of using a "normal ER" tool is really helpful for our first representation of the logical model. Thanks for sharing these ideas. Stefan _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user