XML for large databases

Most likely very inefficient. XML is not a database format. XML advantages include being human-readable and moderately easy to parse (trivial, in fact, if you use a library like TinyXML). However, the file sizes are larger since they are text-based and probably contain a lot of extra information in the form of all the text used for tagging, et cetera. They are also slower to parse (most libraries will read XML files into some kind of in-memory tree representation but that tree won't be ordered in any particularly way -- it will match the file layout as close as possible).

If a database is what you need (compact, fast access times, the ability to do queries and searches, et cetera), use a database. Something like SQLite may work perfectly.

Depends on the language and your XML parser.

There are Java XML databases that claim speeds up there with SQL servers, I believe the Apache project actually has one (all of the rage with the Apache Project these days is Java).

But, there are things to always remember: a fat protocol (XML) will always take longer to parse than a skinny one (binary), so no matter what, you'll never get the same effeciency. However, for a database with only 600 records, I couldn't imagine it would be very far off.

Lastly, before you implement, go window shopping through SourceForge, I'm pretty sure someone's already wrote an XML database system with Expat. Taking a look at it could never harm anything.

Also, it depends on what actions you need to perform on that data.
It could be slow to insert new data or to select a subset using complicated filters. On the other hand, 600 records isn't that much. If you use it for a single server and load it into memory once, performance could be okay.
MS Access definitely makes it easier to query data or execute insert/update/delete commands. You could also use a real database engine, but that might be overkill in your situation.

Maybe you could tell us some more about the system/application you need it for?

Thanks for the replies :) .
One more question: is it okay (performance/memory wise) to load at startup the 600 records into memory? Or its better to load as you need them?

Thanks

one thing though,

using xml is not such a bad idea for performance if you don't plan on using xml files as a data source. parsing your xml files and inserting them into a relational database (still preserving the tree structure using pre/post order indices) you can get a huge performance benefit. that is only of interest to you if you plan on using lots of queries that can be formulated as xpath expressions.

in all other situations there are pros and cons. the situation described above (large volume and only xpath queries i'd favor relational databases without a doubt.

we should really know what you're doing with your data...

cheers,
simon

edit: when i say relational databases i 'm not speaking of access. xpath acceleration and ms access don't play well together performance wise. but you might still beat pure xml files, speedwise.

edit2: only suggesting the technique if you're using the data during the entire computation of your app. this is nothing for initialization-only scenarios (i think this is obvious, but never the less)