Re: Development as Configuration
Date: Thu, 05 May 2005 15:45:40 +0200
Message-ID: <427a2386$0$15638$e4fe514c_at_news.xs4all.nl>
dawn wrote:
>mAsterdam wrote:
>>dawn wrote:
>>>... and then often SQL for persistence, ...
>>
>>Why use SQL for persistence? Any filesystem could provide that, no?
>
> An obvious mAstersam response ;-) so here is mine:
>
> There are two reasons for using SQL as the API for persistance.
> 1) If someone else determined at some other time that a SQL-DBMS would
> be used for storing the data with which my app is working or
Portability of the interface to your data - not persistence.
> 2) If I determined that there were features of a SQL-DBMS that gave an
> advantage over a simple file system so that I chose to use PostgreSQL,
> for example, for a given project. Because SQL is so pervasive in tools
> that have as a PRIMARY feature (smiling) an API for creating, reading,
> updating, and deleting data on secondary storage devices, it is often
> used in even the simplest database applications.
Glad to see you smile :-) But why bother to go the extra kilometer
if a filesystem provides perfect persistence? I think it is good to
use an interface for the right reasons. I suggest persistence is not
the right reason to use a database or SQL. To identify what the true
reasons are, just imagine you would have a filesystem for
persistence. Which problems will you have? To address those maybe
SQL comes back in. But now you have the right reasons, and more
realistic expectations.
> Sure, there are other features that are important for DBMS tools, such
> as security and referential integrity, but many a software application
> has included code for those features too. To date it appears to me
> that people license DBMS tools for the PRIMARY, not negotiable, feature
> of having an API for creating, reading, updating, and deleting data on
> secondary storage devices, even if there are other important features
> too. Right?
