[
Lists Home |
Date Index |
Thread Index
]
> Here's another "something altogether different":
>
> http://www.onlamp.com/pub/wlg/6913
>
> Thoughts?
My comments about that article are based on software processing important or
mission-critical data. If you're blogging and publishing photos of the family
cat, you don't have the same data integrity challenges as a system architect for
SkyQuery.net or amazon.com.
The author wrote:
"In contrast, traditional database design takes as much control away from the
application as possible and puts it in the database. A constraint or trigger or
stored procedure or foreign key can make sure that no one gives someone an
absurdly high salary ... "
Or processes an order and ships a computer to a customer whose account was
closed for non-payment.
"This centralized control is a relic of the 1970s ... "
It's interesting how people try to imply "not modern" is sufficient reason why a
technology or practice is inferior. If we applied that logic when
writing about other topics, we'd be making such credible statements as:
Differential calculus is a relic of the 17th century and has no place in modern
mathematics.
Because Michelangelo's David is a relic of 16th-century Italy, it has little
artistic merit today.
"Nowadays, when an application and even a Web interface stand between the user
and the database engine, the never-trust-the-user philosophy is less valid."
It's more valid than ever.
Computer users in the 70s, even people doing data entry, were trained
specialists. Today the person on the other end of the wire might be
Grandma Beatrice or David L. Smith after meeting a new Melissa.
"At the very least, an application has to know the rules the database is
enforcing and translate error messages into something the user can understand.
The wall between application and database engine is porous, so the application
can take on more of the validation and logic."
Early validation is important -- before data travels across the wire to an XML
data store or database engine. But that's not an argument for reducing the
database role as a rule enforcer.
Moving logic out of databases into applications subverts data integrity. It
creates problems of consistency and version control.
Consider a rule such as not shipping an order to a customer whose account is
closed. If it's embedded in the database, it applies to any client that connects
to the database (Web clients, WAN/LAN clients, Java, Javascript, C++, VB,
whatever). The logic is consistent for all types of clients.
There's a related issue of versioning and change control.
Consider a scenario such as testing facilities dealing with pressures,
temperatures, vibration, length and so on. Global sites and applications
feed data to a central, shared data store. Logic in the database enforces
rules about allowable ranges based on metric values.
Let's say you've done some research and need to adjust acceptable range values.
If the database is the ultimate rule enforcer, you go to one place to update
constraints. The singular database change applies to all clients attempting to
insert or update data. On the other hand, if you delegate that role to software
in the client or middle tier, you're faced with changing a variety of scripts
and programs (possibly in several scripting and programming languages).
Now you have a versioning and change control problem:
1. To ensure consistency, you must coordinate the implementation of rules logic
in multiple places (possibly Web clients, LAN clients, Java, Javascript, C++,
VB and more) . In a mixed language programming and scripting environment,
you can't create a runtime linkable library that's shareable across Windows
and Linux, or a class that's linkable by C++, VB and Java. Making the
change in one place in application code and having it apply to all scripts and
programs is not feasible.
In addition, storing decision-making data as variables in badly-coded programs
can introduce risks (e.g., Mars Polar Lander premature shutdown).
2. You must ensure that all clients use the metric system, for example. The
crash of the $125 million Mars Climate Orbiter comes to mind.
** The point **
Maintaining data integrity by consistent enforcement of rules about data is one
of the primary reasons for using database technology. Many developers don't
understand a modern database is more than a passive data container, so they
don't exploit databases to encapsulate logic and enforce data integrity rules.
|
