NYCPHP Meetup

[bz-gmort at beezifies.com]

Elliotte Harold wrote:
> 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.

I don't see a particular benefit of XML in this regards over a 
traditional relational database.

What I keep getting hung up on is a functional app.

What you seem to be saying here is "I can add a record type whenever I 
need it and call it whatever I want".

So in a hospital, a doctor decides for some reason he needs to track toe 
size of the patient over treatment.  So he adds in a toe-size tag
<toe-size>3</toe-size>

And records that with every visit.

Now 6 months later he wants to chart out the toe size over time...opps, 
application needs to be adjusted to search out all toe-size fields and 
chart the data.


Put it in a traditional relational database model, and instead of adding 
a field, he uses the comments field:
toe-size:3

At the end of 6 months he wants to chart out the toe size over 
time...same effort is involved in pulling the data.

If you know up front the users will need to add extra record types 
periodically, you can design an inefficient means of doing so.
For example:
You have a patient record table with a record_id
You have a keyword table and a data table:
Your keyword table is just keyword_id, keyword_text, 
keyword_description, datatype(integer, text, etc)
Your extra data table is simply record_id, keyword_id, text

Your application lets a doctor add a new keyword(toe_Size) define it as 
an integer, and now he can add the data to the table.

Or maybe you make a dynamic junk field table:
extra_data
Every time he creates a keyword, you add a column to the table

Whatever keywords prove the test of time, they get incorporated into the 
database design model 6 months down the line.

I see small benefits of XML to a relational database in that it seems 
"cleaner" not to have a bunch of records with null data in the table. 
But I don't see a functional difference.  Performance in both cases is 
going to be awful since the data is unindexed and unoptimized.

Where XML seems much better to me is in transferring data from one 
system to another(no placeholder positions) and in giving someone their 
data to go out and play with.

Someone has to go to Japan for a meeting, here is all your data on your 
laptop.  Make changes and sync later.  Opps, you forgot something, no 
problem we can email you the files.

Note: you can do the same thing with a relational database, but users 
think in files.  It is easy to get them to follow instructions to 
manipulate files.  Trying to get them to understand manipulating tables 
and running a local database server just doesn't fly.

> 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.)


How does using XML for storing the data enable more integration?  My 
experience is that the "enablement" tends to be a "we are all learning 
together" phase, where the admins are learning so they don't know their 
best practices yet - and haven't been burned with a programmer sticking 
confidential data in the database and not telling them so it got 
broadcast to the whole company and the manager rightly blamed the DBA 
for allowing it to happen.  Once the new shine fades, you will be right 
back to the traditional struggle that comes about when one group is 
tasked with security and performance of data and another group is tasked 
with functionality and usability.