Re: Big O

Just to play the devil's advocate, a bit. What is a flatfile system? Is this defined by the storage mechanism, i.e. the data is stored in files? In that case, some so-called DBMSs are really flatfile systems. Or does it have to do with the structuring of the data in the file? CSV has a structure and XML even more so, where do they fall? If it has to do with SQL and admin interfaces, those exist for flatfiles.

And if I read the original poster's question correctly, it is phrased in practical terms, not theoretical -- "in most Commercial Situations". Which would make such questions as size and complexity of the data crucial. Storing a few dozen fields for a few hundred registered users in a web context might very well be better handled with a flatfile system depending on the resources of the company involved and other issues. A large data set where speed is critical is another matter.

"Who Me" wrote:

> 3) data integrity and security - use of constraints in the database
> for data, again away from the program

What about the other thread in this group talking about the complexity of OS development as compared to database development? Who knows where OSs are going to go and what kinds of features they will provide? DBMSs are clear winners now, but in the future ...

> 6) reduce app development time - apps can focus on other things and
> can become more robust as data is being handled by the DBMS and a
> simple enough interface is provided.

That one particularly is questionable depending on what tools the app developer has to handle flatfiles, the complexity of the project, the existing format of the data, etc. The flatfile app development could well be less in some situations.

Of course, I'm not advocating anyone drop their DBMS and start using flatfiles, but if this isn't simply an "is King Kong stronger than Woody Allen?" type question, things are not as self evident as they might appear.

-- 
Jeff