Prefer Open Standards to Proprietary Extensions

The temptation to use vendor-specific extensions to SQL should be avoided at all costs. Advocate for use of ANSI-standard SQL, and not proprietary extensions, in access to relational database stores. This concept is applicable to other forms of databases also. For example, an XML database should be exclusively accessed using XPath or XQuery.

For additional information on XPath and XQuery, see XQuery: Kick Start by J. McGovern, C. Kagle, P. Bothner, J. Linn, and V. Nagarajan.


By utilizing a separate data access tier, data architecture can minimize the impact of calling applications since the APIs used by higher tiers do not change. The implementation of stored procedures is another form of proprietary access to a database that should be avoided. Stored procedures are specific to the database implementation in use and are difficult to migrate if a different implementation of a database is required.

For more information on implementing a separate data access tier, see www.agiledata.org/essays/implementationStrategies.html.


Those familiar with Java and J2EE will see this principle represented by Enterprise Java Beans and will notice the preference of the Java community to use container-managed persistence, which does not support the use of stored procedures. The Java community is slowly adopting APIs such as the Java Data Object (JDO) specification that allows for data store independence.

For a great book on Java Data Objects, see Core Java Data Objects by Sameer Tyagi, Michael Vorburger, Keiron McCannon, and Heiko Bobzin.


Use of database triggers is also a proprietary extension of a database. It is a good practice to use database triggers for the sole purpose of supporting referential integrity and no more.



Practical Guide to Enterprise Architecture, A
A Practical Guide to Enterprise Architecture
ISBN: 0131412752
EAN: 2147483647
Year: 2005
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net