Off topic: this is one difficult book to read. Not that it's written in a tangled language (try reading this). It is just that the understanding of content will come with the practice, otherwise the knowledge will evaporate momentarily. But how often does one make architectural decision on the enterprise level? And how often does one decide to use a new set of patterns? So the actual "reading" will take quite some time and I have been reading it on and off for four years already. Yes, I am slow reader.
The only downside is examples. As a sport ignoramus, I have no idea why a Footballer would inherit from a Player but a Bowler should inherit from a Cricketer. So examples are not from my real life and confuse me more than actually explain anything. Instead of understanding relations from entities I have to go in the opposite direction. Bugger.
Meet the Class Field Inheritance pattern.
The idea is that the base class shares a single table with children and the child-specific fields are serialized into a single field. You would use it if:
1. Base class is equal in rights with children classes and has to be instantiated.
2. Child classes have very few extra properties.
3. There is no requirement for an extensive analysis of the child-specific fields.
4. There is no requirement for a raw child-specific data to be available for a database objects (e.g. reporting tools, functions or procedures).
All these requirements are not 100% solid. If the performance is negotiable, concrete child properties can be lazily deserialized, thus enabling a business layer analysis. The raw data from the filed can be "unfolded" using user functions, providing concrete tables to join on them if required.
Pattern is fast in the implementation - one stored procedure will serve it all, and the logical flow is very clear. One can go nuts with Strategies, Abstract Factories and Dependency Injections. Now tell me that it is not a beauty!