Cor Ligthert said:
Gus,
An XML file is just not a database.
-Cor, I say this with the utmost of respect, but I think that statement,
without adding some qualifications, is a bit misleading. The reason I say
this is that while XML is certainly not an optimum database in multiuser
scenarios, it certainly is a decent db in many other instances. XML is a
lot better that relational databases for many heirarchical scenarios and you
can deal with it directly in many cases, negating the need to advanced
extraction routines. Yes, the last part of that point is not valid across
the board, but what I mean is that you can grab an XMl document and deal
with it as a unit quite easily.
There is a difference between a XML file as les say a document (with
attributes etc), (As Bill stated to get with a loadxml) and a XML file
wich is a dataset, what you can get with a readXML.
However both are just files noting more.
--Again, i'd just caution that this point could be a little confusing if you
don't qualify it. Take ISAM Databases which were the predominant way to
handle data for a long time. They were single files. Access is a single
file database. Even Sql server is a a single file in respect to how the
actual db file is created (although admittedly you can split up filegroups).
But Excel, CSV etc are all single file systems in the truest sense of the
word and they all suffice as a database quite well in limited user
scenarios. In fact, I've used ISAM databases that were much faster than a
Sql Server equivalent and actually worked pretty well in multiuser scenarios
b/c the I/O time associated with reading and writing values was so fast that
locking was not much of an issue. In no way though am I saying that XML,
Excel , CSV etc is the optimal way to handle large multiuser scenarios, but
there is definitely a place for this approach in many applications.
Because there are tons of methods
to internally access a dataset, you can use that as well to get the data
and to select of whatever way you want to get a subset.
The pain comes with updating. It is just a file and therefore can you only
write a complete XML file back. This means that it is almost (in fact is)
unusable for multiuser purpose.
--I am not saying that it's great for multiuser scenarios, but single files,
including XML can often perform every bit as well as say Access. I've used
ISAM dbs with well over 100 users and had minimal problems. Indexes needed
rebuilt and maintained, but that's certainly not unique to single file
systems. Moreoever, the IO in many cases can happen so quickly that users
may never realize that someone else was writing to it. Access is another
example, all the changes made on remote machines need to propogate to one
file, and while Access is hardly a good tool IMHO for multiuser scenarios,
many use it successfully - it really depends on the nature of your
application. Also, look at an application like Log4net that writes to one
file at a time. The app is written to allow lazy writes and we used it for
a large scale application written fro the Dept of Revenue at the State of
SC. There were huge numbers of users and at first we had logging set up
very verbose. things happened so fast that even with all the writing going
on, it was not a problem. Sure, effectively one machine was serving as the
'user' but there were hundreds of users at a time hitting that machine, and
each request was writing to the file. The same can be implemented with XML
and I certainly am not advocating it as the best way to go in multiuser
scenarios, when RDMBS systems aren't available, like this case that Gus
mentions, I wouldn't write it off
