| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
Home -> Community -> Usenet -> comp.databases.theory -> Re: Development as Configuration
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 - 08:45:40 CDT
![]() |
![]() |