Dave,
The part from the doc. that you quoted is the key. More precisely the
"in principle" part.
If you employ the relation types mechanism you are making your code more
complex, less readable, harder to maintain now for an unknown potential benefit
in the future.
Another option is to go for a more straightforward solution now that is
sufficient for your current requirements. This might mean that at some point
in future you might have to rewrite some of your code to switch to the relation
types solution in order to gain whatever benefits it might bear.
Kent Beck in his book on XP
(http://www.amazon.com/exec/obidos/tg/detail/-/0201616416/103-1935466-0960636)
reminds that you should also take into account the interest on the investment
you are making today, which will pay off in more or less distant future. Of
course, if it turns out that the benefits in the future never pay off that
investment is completely wasted.
I can tell you a true story about using generic relations in (Open)ACS from a
team working on a very high-visibility project for a Global-50 company:
As you probably know, generic relations are used for representing n-to-n
relationship in the permissions system. After more than a year of working with
OpenACS permission system, and after the system has been successfully put into
production, the team got a change request to implement a functionality to merge
two users. As merging users touches in so many tables in the system, including
the permissioning tables, the team decided that it was about time to simplify
the permission system and get rid of the relation types. As a part of the same
effort they also removed the parties table and put the email field back into
the users table.
Improved performance and code maintainability have proven that that was the
right decision.
This example shows that, in addition to wasting the investment, and the
interest, you might end up spending even more money on revamping the system
just to avoid wasting more resources as you go forward.
