Data storage in XML or SQL?

Question

I am developing a Windows Phone 7.5 application.

I need to save 22 items with the following fields:

• Number (int).
• Name (string).
• Description (string).

The title and description will be in different languages.

Now I use the XML file as follows:

<?xml version="1.0" encoding="utf-8" ?> <cards> <card id ="0" name="Mad" description="xxx" ></card> ... </cards> 

I don't work much with XML, and I'm not sure if this is the best way to do this.

Any tips? What did you recommend to me? I need to save each name and description in different languages.

Answer 1

I would structure your xml as follows

  <cards> <card id ="0"> <name lang="en">Mad</name> <description lang="en">xxx</description> </card> <card id ="1"> <name lang="fr">Brother</name> <description lang="fr">xxx</description> </card> .... etc .... </cards> 

Due to the fact that in this structure you have only 1 attribute for each element, and it is easy to find child elements that are the data you are looking for.

Actually, another question arises that touches on this XML recommendation: attributes and optional elements

Answer 2

Reading messages and tags, I undestand you want to save this data in SQL SERVER. You can have a table with different languages, and XML should contain the name and description of the attributes according to these languages, like name_ES, name_EN, name_FR, ... (same for description).

Then, programmatically, you can have a DataSet object matching the SQL SERVER table. If I am not mistaken, it is possible to independently analyze your XML object of this DataSet.

Answer 3

If you have only a small number of elements, such as reading the entire XML file into memory, this is not a problem, SQL does not give you many advantages. SQL comes to life when you have large, complex databases, and you should be able to query it quickly and flexibly. If you have a lot of data (to load a lot into memory) and you need to selectively extract elements from your database, XML is a pain (you need to parse it and implement logic that will determine the correspondence for your query), while SQL is intended for this, lightning fast, and queries can be arbitrarily complex (well, within reason).