Q
Problem solve Get help with specific problems with your technologies, process and projects.

Data abstraction best and worst practices

Larry Fulton discusses best and worst practices for the ever changing core data relationships within data abstraction.

Can you provide any best/worst practices for data abstraction?

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.

Dig Deeper on Topics Archive

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchAWS

SearchCloudComputing

TheServerSide.com

Close