As for using a RDBMS as a “flat file,” I can tell you that tested benchmarks on commodity hardware shows a near 30-50% hit on sequential scan rates. While this is not the issue in OLTP applications, as you will no doubt be aware, in Data Warehousing sequential scans are the rule, not the exception. Because of that, traditional RDBMS systems are not overly interesting for large data scans.

When your data access model is largely pointer-driven (such as in a network database), then the performance difference is gigantic. In some rough comparisons between PostgresSQL and AllegroCache, I observed order of magnitude or more differences in graph usage. No relational database is designed to handle massive graph-style queries like reachability, condensation, cycle removal, etc. This is especially painful with digraphs that have cycles in them.

I understand that for many applications, RDBMS is an acceptable solution, but to argue that because you’ve never seen it collapse into a gigantic morass of tangled query planner attempts doesn’t mean it doesn’t happen.

When you propose flat files for reporting, you forget RDBMSs can be used in exactly ðe same way, while also making normalised data available for more dynamic uses.

When you talk about forensic analysis proposing object or graph DBMSs, you forget you are fixing a few data acceß paþs in detriment of all others. It may be nice for reporting, but you can do ðe same with foreign keys on the logical side, indexing and materialised views on ðe physical one; when you talk about linking, you are mixing up the logical and physical levels.

Same for real time analysis. In fact, due to normalisation, RDBMSs are uniquely suited for in memory databases.

Don’t let current implementations blind you to concepts and poßibilities.