Xml or Sqlite, When to drop Xml for a Database? [closed]

Answer 1

A database is great as part of your program. If quering the data is part of your business logic. XML is best as a file format, especially if you data format is:

1, Hierarchal
2, Likely to change in the future in ways you can't guess
3, The data is going to live longer than the program

Answer 2

You should note that many large Relational DBs (Oracle and SQLServer) have XML datatypes to store data within a database and use XPath within the SQL statement to gain access to that data.

Also, there are native XML databases which work very much like SQLite in the sense they are one binary file holding a collection of documents (which could roughly be a table) then you can either XPath/XQuery on a single document or the whole collection. So with an XML database you can do things like store the days data as a separate XML document in the collection... so you just need to use that one document when your dealing with the data for today. But write an XQuery to figure out historical data on the collection of documents for that person. Slick.

I've used Berkeley XMLDB (now backed by Oracle). There are others if you search google for "Native XML Database". I've not seen a performance problem with storing/retrieving data in this manner.

XQuery is a different beast (but well worth learning), however you may be able to just use the XPaths you currently use with slight modifications.

Answer 3

When should XML be used for data persistence instead of a database? Almost never. XML is a data transport language. It is slow to parse and awkward to query. Parse the XML (don't shred it!) and convert the resulting data into domain objects. Then persist the domain objects. A major advantage of a database for persistence is SQL which means unstructured queries and access to common tools and optimization techniques.

Answer 4

XML is good for storing data which is not completely structured and you typically want to exchange it with another application. I prefer to use a SQL database for data. XML is error prone as you can cause subtle errors due to typos or ommissions in the data itself. Some open source application frameworks use too many xml files for configuration, data, etc. I prefer to have it in SQL.

Since you ask for a rule of thumb, I would say that use XML based application data, configuration, etc if you are going to set it up once and not access/search it much. For active searches and updations, its best to go with SQL.

For example, a web server stores application data in a XML file and you dont really need to perform complex search, update the file. The web server starts, reads the xml file and thats that. So XML is perfect here. Suppose you use a framework like Struts. You need to use XML and the action configurations dont change much once the application is developed and deployed. So again, the XML file is a good way. Now if your Struts developed application allows extensive searches and updations, deletions, then SQL is the optimal way.

Offcourse, you will surely meet one or two developers in your organisation who will chant XML or SQL only and proclaim XML or SQL as the only way to go. Beware of such folks and do what 'feels' right for your application. Dont just follow a 'technology religion'.

Think of things like how often you need to update the data, how often you need to search the data. Then you will have your answer on what to use - XML or SQL.

Answer 5

1. Use XML for data that the application should know - configuration, logging and what not.
2. Use databases(oracle, SQL server etc) for data that the user interacts with directly or indirectly - real data
3. Use SQLite if the user data is more of a serialized collection - like huge list of files and their content or collection of email items etc. SQLite is good at that.

Depends on the kind and the size of the data.

Answer 6

To me it really depends on what you are doing with them, how many users/processes need access to them at the same time etc.

I work with large XML files all the time, but they are single process, import style items, that multi-user, or performance are not really needs.

SO really it is a balance.