Re: Development as Configuration

From: mAsterdam <mAsterdam_at_vrijdag.org>
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?

IMHO DBMS tools can deliver their benefits by encapsulating, hiding storage considerations from the application. Delivering storage to the application is the means, not the end. You don't want a room, you already have it. The DBMS is the locks on the doors and the organization of the room - not the room itself. Received on Thu May 05 2005 - 15:45:40 CEST

Original text of this message