Database Reference
In-Depth Information
CHAPTER 11
IN
SQL S
ERVER
Our journey has brought us a long way, and now we're near the end. At this
point you should have a fully working physical database complete with all
the appropriate indexes. This is the time when many database modelers
stop their work and toss the database over the wall for the DBAs to imple-
ment and manage. If you choose that course, you may be just fine, but you
might also be setting yourself up for failure. In its current state, access to
the database will be pieced together by the application developers, and
trust us when we tell you that most application developers do not under-
stand how to access a database in the best way.
No, to be complete you have one more step, one last thing to build and
that is the topic of this chapter. We look at how you should go about build-
ing an abstraction layer on top of your database in SQL Server.
Before we get too far along, you need to understand what an abstraction
layer is. In general terms, an
abstraction layer
is a way of hiding the com-
plex details about the functionality of a process. It could be thought of as a
user interface, although in this case the user doesn't have to be a person.
Let's look at a car as an analogy. Your car has an engine, and that engine
does many complicated things to make your car move. Do you understand
everything that the engine does? For many of us, the engine is just the big
apparatus under the hood. The only thing most of us know how to do is
look at it and pretend we know what we are looking at. For the common
folk, we know that if we put the car in gear and step on the gas, the car will
go. That system of the gear shift and the gas pedal is an abstraction layer;
it allows us access to the underlying complexity of the engine's function
without our needing to know a thing about it.
241
Search WWH ::
Custom Search