views:

305

answers:

3

I have two web forms which are filled in by the user. They contain different types of fields: text boxes, radio buttons, check boxes (single or in groups). All the information that user submits I store in XML field in a database.

My question is: what are the good practices for string that kind of informations in a XML file.

For now I do like this:

Text boxes, for example: txtName I put into <Name>John</Name> tags.

Radio boxes, for example: rdbSex I put into <Sex>Male</Sex>.

Check boxes groups I put into one XML tag and I specify true or false for each check box item, for example:

<favoriteMovies>
    <StarWars>True</StarWars>
    <KillBill>False</KillBill>
    ....
</favoriteMovies>

The movies are stored in the database in one table and each of those have an ID. Should I store it also in the XML file? Like this:

<favoriteMovies>
    <StarWars id="4">True</StarWars>
    <KillBill id="6">False</KillBill>
    ....
</favoriteMovies>

or maybe to store only selected choices (withoud KillBill in this case):

<favoriteMovies>
    <StarWars id="4 />
    ....
</favoriteMovies>

The same problem is with dropdown controls. They are populated from one table in database and each item has an id. Should I store only the id of the user choise, or both: id and name of the choice. So it is better to store do like this:

<Address>
    <City>2</City>
</Address>

or like this:

<Address>
    <City id="2" />
</Address>

or like this

<Address>
    <City>New York</City>
</Address>

The documents are submitted by the user, but they can be reopen and edited, and all the controls on the web site should be repopulated. So it seams I need ID of the city, to select appropriate value in DropDown control, but it makes the XML document less readable.

Are there any recommendations or some documents that specify the rules for storing web forms elements in XML documents?

+1  A: 

I think you should take pragmatic way: using attributes for atomic values can lead to smaller XML documents. I'd also prefer this:

<favoriteMovies><!-- all this are favorite, so "true" isnt required -->
    <Movie id="4" name="StarWars (just if required)" />
    ....
</favoriteMovies>

Over this

<favoriteMovies>
    <StarWars id="4">True</StarWars>
    <KillBill id="6">False</KillBill>
    ....
</favoriteMovies>

Note I removed KillBill, as it's marked as "not favorite".

Bottom line: keep your XML document small and you'll not have problems.

Rubens Farias
+1  A: 

I would go this way:

1) Treat what you want to put in you XML as objects

2) Find what property best describe you object for humans, put this between the tag

3) Every other attributes that decorates the object, put them as tag attributes

I will re-take Rubens examples with a modification:

<favoriteMovies>
    <Movie id="4">StarWars (just if required)</Movie>
    ....
</favoriteMovies>

I moved the name because this is what best describe the movie (for humans) and because if you have special characters, you will be able to <![CDATA[ ]]> them...

Hope this helps

Mike Gleason jr Couturier
I think you should not be influenced on how to construct your XML by the origin of the data (as long as it's there). That's why you can look around for examples of XML files and best practices. I gave small hints in my answer but ultimately, it's up to you! Good luck!
Mike Gleason jr Couturier
I was thinking that maybe there exist some standard on how to do this. Maybe in future I would like to move my informations to other existing application so I don't want to encounter any problems then. But anyway, thanks for great explanation.
Lukasz Lysik
A: 

I would not store XML documents in the database (Especially since they seem to be transport type objects). Why not just store the data in a relational way in the database. Forms are good for capturing the data. XML is good for transporting the data and database tables are good for storing the data. Since you are already storing the movies in the database it should be easy to store the rest of the data in the database explicitly rather than implicitly via the XML.

Johan
As I commented @Raj More. The structures of the forms are very flexible. Some of the fields can be removed in the close future and some can be added. Other thing: there are two different forms that are stored in the same table. In the future it can be 3 or even more. I don't think it is good idea to have different table for every form. Besides, Microsoft recommends using the XML data type in the cases, when structure of the data can be different (Microsoft, SQL Server 2005, Implementation and Maintenance, page 256)
Lukasz Lysik