First, Sorry for the late reply.
Yes, there are examples of large transactional database systems using this approach, but unfortunately I am bound by NDA:s not allowing me to provide any specifics.
The reason why performance does not suffer (much) is that transactional queries tend to be very "narrow". For example, if you want to retrieve the information for a single entity, say a customer, then once the surrogate identity of that customer is established the clustered indexes for each table can be used to retrieve the information. You will of course have more index lookups than a single table, and also disk spindle movement if you're not on SSD:s or have intelligently parittioned your data. So, some performance will be lost compared to having it all in a single table, but not much.
In practice, there are probably very few scenarios in which this small loss of performance outweighs the benefits of having a flexible and extendable model capable of handling of historical data.
I agree that some sort of quick reference is a good idea. I'll see what I can do in that area as soon as possible. It may still be a while though as other things have higher priority at the moment.
