The Future of XML Documents and Relational Databases

5 Comments

1. 2003-07-31 5:50 am

   Anonymous

   I dunno.

   The idea of putting the business logic (of creating documents) into the database logic sounds weird to me, even if there are performance gains.

   The maintainability of this code becomes much harder. Seems like a step backward to me. If you think I’m wrong please add to this as I want to understand why this is a good thing.
2. 2003-07-31 6:45 am

   Anonymous

   Storing XML in a SQL database can be a good thing. For example, if you have a bunch of data in your database that you want to place in an XML document for human consuption, then it would be easier to store that data in an XML format in the database to begin with rather than reading it from the database as stardard text and then creating the XML document programatically.
3. 2003-07-31 8:46 am

   Anonymous

   The idea of putting the business logic (of creating documents) into the database logic sounds weird to me, even if there are performance gains.

   I don’t think that’s the point of XML driven databases. The truth is that RDBMS’s really don’t do structured or heirachical data very well (in fact it’s a momentous effort of looping round recordsets spawning off more recordsets). All the XML is doing is giving you a way of better representation of your data. After all RDBMS’s were supposed to remove redundancy and repetition but unfortunately due to the flat structure of their output promote it. For example, a query to return children of a parent is like so:

   Parent Child

   —— —–

   Mr M Son 1

   Mr M Duaghter 1

   Mr M Baby 1

   Then add the relation of two parents and you have a nightmare. XML represents in this form which is far more efficient, especially when you wish to manipulate and displaying the data:

   <parent>

   Mr M

   <children>

   <child>

   Son 1

   </child>

   <child>

   Duaghter 1

   </child>

   <child>

   Baby 1

   </child>

   </children>

   </parent>

   Also, with DTDs and Schema’s etc it gives you another level of maintiaing data integrety that traditional SQL databases just can’t offer.
4. 2003-08-01 4:19 am

   Anonymous

   Iconoclast wrote: it would be easier to store that data in an XML format in the database to begin with rather than reading it from the database as stardard text and then creating the XML document programatically

   Databases should care about storing data and not how it is supposed to be consumed. Business logic is supposed to care about managing data and making it useful to people. Presentation logic is supposed to allow users to interact with the business logic in a simplified manner.

   Granted, the example you offered makes the initial programming task easier. However it throws away the above ideals of logic separation. If one were to take your “human consumption” example to the extreme it might sound that the DB is placed in charge of not only the business logic but also the presentation logic.

   The current movement to separate logic is really taking off right now and this is going in another direction. Take Macromedia’s Flash Rich Internet Application framework and the upcoming Central architecture. They give all the presentation logic to the client where the server cannot access it. The business logic (PHP, ColdFusion, FCS) is merely in charge of providing the data to the presentation logic for massaging and take the data back for storage. If it were all in XML then we’d have to force all 3-tiers to understand XML. This might sound great but there are instances where XML is not the greatest technology.

   I’m sure this SQL/XML hybrid stuff will take off because there is no doubt good to come from it but mixing logic is not one of them.

   My 2 pesos.
5. 2003-08-01 4:22 am

   Anonymous

   Peter Moss wrote: All the XML is doing is giving you a way of better representation of your data.

   Good argument Peter. Thank you for your feedback.