NYCPHP Meetup

[Elliotte Harold]

Tim Gales wrote:

> Valid XML documents must adhere to their DTD/Schema and to that
> degree they have fields -- called 'elements'.
> like


Which is why we don't necessarily use valid XML documents. For many 
applications, well-formed is good enough. In practice, validation is 
usually one of the first things to be turned off in a production app 
because it just costs too much. However there are also good theoretical 
reasons not to insist on enforcing a schema.

At design time, you usually don't know all the characteristics of the 
data you're modeling. It is common to uncover new attributes months and 
years after you've deployed, especially in rapidly changing fields like 
medicine. The less structure you impose up front, the more freedom you 
have to adapt and evolve your database and application to changing 
circumstances.

As Scott Ambler has noticed, the data community has not yet graduated 
from the waterfall, big-design up-front school of application design. 
First they gather their requirements. Then they build their schemas. 
Then they build their application on top of that.  Once an app is 
deployed, even a simple addition of a field can be a major operation. 
Lord help them if they need to remove a field or restructure a table. 
Relational databases do not lend themselves to agile development.

By contrast, if you don't lock in any schema at all (as is possible with 
an XML DB) then you can adapt your data to meet changing and newly 
discovered requirements as they become apparent. You can also design and 
deploy your application in short iterations that progressively add 
functionality. You don't need to lock down your requirements before 
writing any code.

This also enables and requires much greater integration between the 
database admins and the programming teams. Too many organizations today 
treat these as separate fiefdoms. The DBAs spend all their time 
optimizing the database and defending its purity from the demands of the 
programmers while the programmers spend their time trying to work around 
the strictures the DBAs have imposed. (I've usually been on the 
programmer side of this particular battle so my perspective here is a 
little biased.)

A more flexible, less schema focused database will not require 
programmers to wait for weeks, months, or years for the DBAs to make 
changes applications require.

-- 
Elliotte Rusty Harold  elharo at metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/