Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Something altogether different?
 > 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@s...> 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
