Yes, but I believe SQL Server 2005 better supports XML, natively storing it as an xml type, and letting you do queries and updates on xml files as if they were tables.
Russ > -----Original Message----- > From: Robertson-Ravo, Neil (RX) [mailto:Neil.Robertson- > [EMAIL PROTECTED] > Sent: Thursday, June 29, 2006 10:50 AM > To: CF-Talk > Subject: RE: XML storage of metadata in database fields > > Has done since 2000. > > > > -----Original Message----- > From: Snake [mailto:[EMAIL PROTECTED] > Sent: 29 June 2006 14:39 > To: CF-Talk > Subject: RE: XML storage of metadata in database fields > > BTW SQL Server now supports XML natively, so if you store XML in the > database, you can parse it a lot easier. > > Russ > > -----Original Message----- > From: Jochem van Dieten [mailto:[EMAIL PROTECTED] > Sent: 29 June 2006 13:39 > To: CF-Talk > Subject: Re: XML storage of metadata in database fields > > Katz, Dov B \(IT\) wrote: > > There are several approaches to solving this type of problem, imho, > > and each one has costs and benefits, and I've given each of them a > > "report card" (A being best, F being worst): > > > > 1) Xml into a field (as originally speculated) > > Benefits: flexible design, structured data once retreived > > Costs: useless for searching > > Unless your database supports functional indexes. > > > data not typed, (all strings) > > Unless your database supports schema validation. > > > storage bloat due to markup > > Not that bad if the database supports inline compression. Columns have > overhead too. > > Jochem > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:245077 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
