[
Lists Home |
Date Index |
Thread Index
]
> 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.
Apparently you've never met my family's cat (or most family's cat for
that matter ;)
On 4/22/05, Ken North <kennorth@sbcglobal.net> wrote:
> > 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.
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
--
<M:D/>
:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist
|
