Stuart Langridge, writes about why he doesn’t like databases and why to “use the filesystem as your database” (in context to the backend of a blog, I guess). IMO, it may hold some value to design a filesystem-driven data tier for ease-of-deployment or ease-of-maintenance?(not that RDBMS?administration these days is a highly complex affair for a?sound DBA) or in the situation of “limited resource architecture” (where a physical database server may not be a feasible data source).?But for ANY enterprise-level?system or?data-centric application,?a database system undoubtedly provides high performance, efficiency, maximum storage capacity, extensive set of tools & components?for interaction and management, a programming interface (i.e. SQL) and rapid integration capabilities (i.e. XML/SOAP) with legacy systems or other data sources. Persisting binary data (data blobs) in a database server is another story. Its a known fact that in a scenario where data query and server round-trips are high or constantly increasing,?a filesystem-based data tier will bog down the entire application much quicker than a dedicated database-server. Talking of a larger picture, I doubt even Microsoft is moving away from this fact, with increased efforts to create a robust filesystem?powered by a database?engine (i.e. Longhorn WinFS). Filesystem vs database is an on-going discussion with two sides to a story. Considering SQLite, MySQL and PostgreSQL as inexpensive database server alternatives, I doubt cost has much to do with it.
[Quick Tip]?Checkout OLAP Scribe -?a utility for documenting your Analysis Services databases. It generates detailed information on the components you select. For example, it will tell you about the dimensions, measures, calculated members, source tables, last processed date, size, and read-only status of a selected cube. Definitely something you want to get & run periodically for snapshot documentation of your system. [via Christa Carpentiere]