What is needed is a multi-featured data store. 1. Traditional Relational with standard SQL 2. Object Oriented Data Storage
Yes... I was teasing about the original comment that the configuration file should be placed in a database. There was a time when loading a file once for an application of that size would be a big issue. Yet today the memory and speed of machines have changed the dynamics of the original consideration. On this you will find me in agreement that for things like Machii this is a viable tool for the task. I don't care if there are 5000 methods... things like that aren't changing regular so if Machii cached the configuration... then that is fine. (It does from what I remember in production.) My comment is there are times when a structured data store would be much better than a related flat file store scheme. Let's take for instance persistence on CFCs. What if we could store the object structure in an object oriented data source and pull it back out without having to do some convoluted translation into a related flat file data store. This process is obscure and not best practice. ( vs. it might be best "available" practice in some instances... since they don't have an Object Oriented Data Store.) Now to your argument that they still haven't caught on... I heard that argument for the longest time about CFCs! When they did catch on this list was started. WAAAHOOO!!! Just because we as a community can be a little thick doesn't prove or disprove the viability of a solution. There are serious drawbacks... hmmm, isn't there a regular discussion here about design patterns? The question is the more effective solution for a given scenario. If it's a XML file, use it. If it's a related flat file data store, use it. If it's a OODBMS, use it. Each of them are best solutions for given scenarios. It's time to rethink things... and if a particular use of OODMBS isn't good, then don't use it. There are other times where it is very good. The bad uses don't make the good uses bad and the good uses don't make the bad uses good. That logic fails. The point is that there are many good uses and it is viable to consider large enterprise sites using a OODBMS for storing things like the config file. It's a choice that to me would be between and XML file and OODBMS. My point is that this is an alternative for someone like the poster who said they didn't want an XML file. It meets his design perspective much much better than a flat file relational database scenario. Thanks for the objection either way... heh. John Farrar -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Woodward Sent: Friday, October 28, 2005 9:49 AM To: [email protected] Subject: Re: [CFCDev] CFSQLTool debate On 10/28/05, John Farrar <[EMAIL PROTECTED]> wrote: > Again... when we use related flat file databases, you are right. XML is > difficult. But if we used something like Cache which is a native object > oriented data store then your objection is immediately obsolete. Not really--what advantage does storing the XML data in an OODBMS database have over having an XML file? Requiring people to not only use a database just to get the app even up and running, but making them use an obscure solution like Cache is utterly ridiculous. I don't care what the database can or can't do, it's not a "better" solution than a plain old XML configuration file. > What is > needed is for databases to evolve. The issue is why haven't data storage > structures matured beyond the original sql store concept in years? OODBMS have been around for years and they still haven't caught on. Do a bit of research--they're a decent solution in certain fringe cases, but they have significant drawbacks as well, which is why they haven't see widespread adoption (and may never see widespread adoption). > Related > flat files with a query language need to grow into object oriented schema > based structure. The time is come and past. There are actually XML databases > on the market. It seems to me that there would be a Machii solution that > employs the power of a XML database like cache or something. I still don't see how this makes anything better or solves any problems with using an XML file. What you're proposing sounds like a solution to a problem that doesn't exist using a technology that no one uses for numerous very good reasons. -- Matt Woodward [EMAIL PROTECTED] http://www.mattwoodward.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
