Or in a case where you need to store lots of information about things which are not consistent without needing to continually reinvent your database. I did this for a RuleManager component where the XML is a way of storing information about business logic handled by a CFC facade. The choice of XML to store this data is due to the ambiguous nature of business logic (i.e. when you don't know the context, you have no idea what will be used in the business logic), although the atomic data elements used by the RuleManager facade (individual object properties) are liable to be stored separately in regular SQL tables.
I'm also doing something similar (or planning to) with my contact manager plugin (People onTap) to store and manipulate the formats for different contact mediums like postal addresses and phone numbers, because the formats for these things vary greatly from one region to another (i18n of course, handling international phone numbers and addresses in many different countries). In this case it's not strictly necessary that the individual contact data be stored in a way that's horridly efficient for the database, as when you're searching for a contact what you want is contact information for a person, rather than a person to go with contact information. So each person (contact) has an XML packet containing their set of phone numbers, postal addresses, email addresses and fax numbers. So my answer would be -- yes and no -- it really does depend on the situation, but more often than not I stick with db storage. In some rare cases when I find db storage to be strange and cumbersome (business rules, international contact info) then I resort to XML with a CFC facade to manage it. > I would say it depends on how much data you are going to > be storing, > both in terms of number of records, and number of > columns/fields. If > these files get to be huge, it could cause some slowing > down, but if > they remain small it shouldnt be too bad. > But really, the only reason you would want to use xml for > a database > is if you had multiple platforms/code systems etc that > were going to > be using it. Things will be much faster and efficient > using an actual > db. not to mention just the queries will be a lot easier. > On 9/13/05, Will Tomlinson <[EMAIL PROTECTED]> wrote: >> Hey guys, >> >> I'm workin' with my new cart app project and the db >> schema/product options/queries are flat out insane. Looks >> like NASA got involved with it! >> >> XML looks like it'd be much more natural in structuring >> the data. >> <item> >> <id>123</id> >> <color>red</color> >> <size>large</size> >> </item> >> >> etc ... etc ... >> >> Is there any way I can use an XML doc instead of a db for >> this purpose? Or would it be just totally inefficient? >> >> Thanks, >> Will s. isaac dealey 954.522.6080 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.fusiontap.com http://coldfusion.sys-con.com/author/4806Dealey.htm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:218138 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
