在数据库中将数据另存为xml与保存多行数据

Question

I am designing my database and wanted to know the best way to handle this problem. I have tabs on a page that looks like this:

Tab1
--SubTab1
----Data1
--SubTab1
--SubTab1
Tab2
--SubTab1
--SubTab1
--SubTab1
Tab3
--SubTab1
--SubTab1
--SubTab1

I can put this information in the database that will be stored in multiple rows like this

TypeID---------------Name
1--------------------Tab
2--------------------Data


ObjectID----------Parent-------------TypeID
1-----------------0------------------1
2-----------------0------------------1
3-----------------0------------------1
4-----------------1------------------1

Or I can just put this in the database like so:

<root>
     <tab name="MyTab">
          <tab name="MySubTab">
               <data>1234567890</data>
          </tab>
     </tab>
</root>

If I pull just the xml from the database then I would not need to select multiple rows i just need to select one row then parse the xml into a class then pass that data to the controller. I just would like to know if this is a good idea? Will I be making a mistake if my site to scale in the future? Will this make more maintenance as the site gets bigger and want more features?

Answer 1

XML is hard to query using SQL. If you think that you will never need to query the data you could use XML. I'd probably store the data in multiple rows for future flexiblity.

Answer 2

If your data is one big lump of xml you can't use the database to easily search that data. Do you need to search for information in the xml? Separating it will make that task easier.

Answer 3

Maybe I misunderstood it but it seems like you are deciding whether to save the data as XML or save it in tables then query it using xml to return it. If that's the case:

Easier to query and can handle more changes: Saving the data to tables and querying it later is better if you will have many changes and it will grow at a high rate. You get more choices for complex querying.

Faster if data doesn't grow or change that much: If the data wont change that often and there is no danger of it growing as much then you can simply use XML to keep it in the right syntax already and it will have less of a performance hit. This method means that you have less flexibility in querying for the right data.

Answer 4

If you are considering whether to store XML on the database it is time to start asking yourself whether storing this data on a database is even necessary.

What about storing this data on a static XML file? Is it a viable option? Why and why not?

If this data does not change frequently and you do not want to invest the trip to the database, but you still want to make sure it is possible to edit this data in the future using a CMS, then it is also possible to create a batch process that creates the static XML file using the data in your database and then your application would completely ignore the fact that this data is in the database and just use the static XML file. The batch process would run on a schedule or on-demand.

This is a scalable, maintainable and efficient way to approach this issue for data that doesn't change often.

A similar way to achieve the same is having a server-side technology like ASP.net or PHP generate the XML for you from the database tables and then using output caching with a long expiration time to make sure that the generation process does not run often.

As a general rule of thumb, it is usually not a good idea to store non-primitive or complex data on a database field.

Answer 5

If using SQL Server, I would just use hierarchyid . While this is possible to do with XML in TSQL, there are several caveats with it. The foremost is getting ordered XML back sucks because TSQL (2008) does not correctly/entirely support position() . It requires a somewhat messy join to an 'indexer' column. (This doesn't apply if you read the entire XML blob back, but this just sounds like a head-ache to parse manually client-side).

hiearchyid allows these levels to be saved easily, leaves the database in a more normalized format (RDBMS' are designed to work efficiently over many columns, just make sure to have the correct indices), and should be much easier to deal with in general -- esp. if you are not ready to dive into SPROC land :-)

hiearchyid represents parent/child relationships as well as ordering of siblings (it can really tidy up the model); it is based on a depth-first model that works well for tasks like this.

Also, using XML will likely save nothing (IIRC, [typed] XML is actually exploded into some kind of internal column setup). It (XML) is much better just to use as a "in/out" message format (or "document"), if required.

Happy SQL'ing.