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 [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/ _______________________________________________ New York PHP Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk NYPHPCon 2006 Presentations Online http://www.nyphpcon.com Show Your Participation in New York PHP http://www.nyphp.org/show_participation.php
