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