We've been encouraging use of the CR in part to keep the differences between RDBMS engines in regard to their handling of large binary and text data buried in one place.
<p>
It also allows storage in the file system rather than in the db, and packages might want to (optionally) expose that choice to system administrators when the package is mounted, etc.
<p>
And we'll be building our sitewide search facility on top of the CR (in PG's case), so clients will get that for free.
<p>
Arguments against:
<ul>
<li>Complexity. As you've mentioned, the CR comes complete with folders and the like. Not sure I would've made that decision myself.<p>
<li>Unknown Scalability. In theory, indexing helps a lot here, i.e. every time you double the number of items the cost of accessing an item goes up by a factor of log2. For large binary content the cost of delivering it is high regardless of any overhead in accessing it. The LRU cache employed by any reasonable RDBMS should keep localized references in RAM, and if the usage pattern is such that you start getting disk I/O this would be true even if various packages were rolling their own.
<p>So, I don't see any particular reason why the CR won't scale reasonably.
</ul>
So at this point the CR seems to be a win rather than a lose. As time goes on we may learn otherwise, but that's the current thinking.
