Explanation --- The content hierarchy is a very valuable asset. So don't just let it happen, design it. If you don't have a "good", human-readable name for a node, that's probably that you should reconsider. Arbitrary numbers are hardly ever a "good name".
While it may be extremely easy to quickly put an existing relational model into a hierarchical model, one should put some thought in that process. In my experience if one thinks of access control and containment usually good drivers for the content hierarchy. Think of it as if it was your filesystem. Maybe even use files and folders to model it on your local disk. Personally I prefer hierarchy conventions over the nodetyping system in a lot of cases initially, and introduce the typing later. Example: --- I would model a simple blogging system as follows. Please note that initially I don't even care about the respective nodetypes that I use at this point. /content/myblog /content/myblog/posts /content/myblog/posts/what_i_learned_today /content/myblog/posts/iphone_shipping /content/myblog/comments/iphone_shipping/i_like_it_too /content/myblog/comments/iphone_shipping/i_like_it_too/i_hate_it I think one of the things that become apparent is that we all understand the structure of the content based on the above example without any further explanations. What may be unexpected initially is why I wouldn't store the "comments" with the "post", which is due to access control which I would like to be applied in a reasonably hierarchical way. Using the above content model I can easily allow the "anonymous" user to "create" comments, but keep the anonymous user on a read-only basis for the rest of the workspace.
