What's the right balance and why? Many small, related content types or fewer larger ones with less internode relationships??

For a flexible, scalable Drupal site, are you better off modeling your domain and it's related content as a large number of smaller/related content types ('related' using say nodereferece+nodereferrer), or as a smaller number of larger content types with less inter-node dependencies?

What are the performance implications one should be aware of that should steer you in one direction or the other? Assume you the purpose of discussion that you are planning on using Views, Panels, Organic Groups to mix and match content and display in various contextual ways

What considerations should you make regarding how the content will be managed, used and viewed when planning out your site?

If you plan to have user generated content associated with your centrally managed content, does this impact you planning/architecture and if so, how?

What over-riding competing factors should you take into consideration in your architecture?

Perhaps a concrete example will help.

Say you were modeling your site around a database of golf courses, clubs, etc and you want to build a multimedia, knowledge base that would be useful to golfers.

You want to be able to manage and display your content in a variety of ways and leverage jquery ui widgets. Users of the site will comment and generate user-generated content on clubs, holes, courses, services, nearby amenities etc.

Content will include photos, videos, text, etc, etc. ... Some multi-media will be stored on your servers, some will be served up remotely.

Golf Club (might be members only, semi-private, etc.)
- Membership Info
- Golf Course
- Carts
- Caddies
- Hole
- Fairway
- Green
- Bunkers
- Nearby Hotels
- Nearby Restaurants

There are a number of ways you can model this domain with cck content types (ct) . Every entity in your domain could have it's own content type and then you'd manage the large number of node:node relationships using a combination of nodereference plus nodereferrer fields, or you could collapse a few of these data structures into a smaller number of larger content types.

Questions like the following come to mind ....

e.g. information about Carts could be kept in a separate ct, or it could be included in the Course ct

e.g. assume each Hole as a separate ct, what about Fairway, Green, Bunker?

e.g. clearly if a certain data nugget is relatively simple and the relationship to it's parent is one to one then you will probably include that data nugget within the parent ct, when will you NOT do this and why for entities related 1:1?

e.g. if you go granular with your domain to content type mapping, thereby taking one the overhead of managing more relationships, will issues like orphaned content types instances and complex relationship management issues kick in at a certain point?

e.g. how deep is too deep? ... if you get into a deep hierarchical structure in your node:node dependencies, when will inefficient SQL queries and "too-many-joins" impacts kick in

e.g. When are you better off doing what could be argued to be a looser coupling amongst content types outside the bounds of CCK using say the Taxonomy module, the Node Relativity module?

e.g. If you want to the easiest upgrade path from Drupal 5 to 6 when CCK and Views are ready? Should you avoid, say the use of Node Relativity?

e.g. Ok, and maybe a dumb questions, but ........ Is 'betting the farm' on leveraging CCK nodereference fields and nodereferr fields a fool's game? Assuming no .... please boost my confidence that this is a good way to go :)

Thx!