Data abstraction best and worst practices

This is a little vague as to the context. If you are talking about defining data service interfaces, I always recommend looking at consumption expectations - in other words, make the service easy to use. If for example you expect to have a lot of development of custom Web sites accessing customer data, make sure the abstraction makes that development easy, even if you have to provide an interface just for those developers. Remember, you will create a service once (ideally) but consume it many times.

If you are asking this more generally, remember that you can't make things simpler than they really are, and your business is going to change. Core data relationships that exist today will be different in a few years, so plan accordingly. A simple example, five years ago in the cable industry, a "customer" and a "premise" were virtually the same. Today, "customers" are frequently billed for multiple "premises", and this of course broke a lot of systems. As a basic rule, plan for change.