>>I think the point is that all too often applications are built with crude substitutes for what would be regarded as a "real" database, only to discover at some later point that they shouldn't have punted this issue in the first place. One of the main reasons that this happens is that few programming languages have cleanly integrated facilities for DBMS functionality. FoxPro shines in this respect, because it is a powerful general purpose programming environment with integral DBMS features that were not merely added as an afterthought. Consider, for example, products like MS Outlook and Outlook Express. These products could really have benefited from being built on top of some sort of clean generic DBMS like Visual FoxPro, instead of the whatever-the-hell-it-is home grown data structures buried inside of them. Using a true database product to manage persistent data structures leverages the tremendous available power of modern DBMS software, and greatly facilitates application
>>integration. When you look at most real world applications, it's not hard to find persistent data structures of some sort that could benefit from residing in a real database, even if it's just a small one.
>>
>
>I think you need to realize that most of these apps do have a -real- DBMS interface via LDAP and ADO and automation; there are lots of things which benefit from a non-relational data model, and incurring the overhead of integration of a database into everything doesn't fly - anyone else remember PICK? There were many othr fail db-centric systems which failed.

Hey, I never said relational - I mean a persistent, structured, managed data store.

Sure, "overhead" is too much on some systems but capable stores are getting smaller and smaller, and available hardware keeps getting bigger... clearly the trend is for apps/systems to have the capability to include data management. The question is whether the designers have the foresight to do so.

And sure, you can "pick" out all kinds of DB-centric systems that have failed. There are lots of non-technical reasons for that, in many cases (what do you think the consensus will be on VFP 15 years from now?). Also, a lot of data-based systems were "ahead of their time", a euphemism for "not enough hardware to run them well, so they were performance pigs".