Re: SQL
- From: "frebe" <fredrik_bertilsson@xxxxxxxxxxx>
- Date: 24 Jan 2006 23:11:09 -0800
>>* Queries.
>Those I'd generally consider to be part of the relational model
Correct.
>>* Transactions.
> Those are definitely useful, but are not specific to databases
Correct.
>>* Referential integrity
>... has to be maintained somehow: dangling references would be a problem
>in any system
>>* Caching.
> Caching also isn't specific to RDBMS:es.
Correct.
My point is that these features are useful non-persistence features
provided by a DBMS.
You claimed: "If we ignore the persistence aspect, what remains is the
organization of data according to the relational model. That's
certainly useful, but it's not 'MANY' features. "
I claim that a (R)DBMS provide MANY useful non-persistence related
features. I don't claim that a RDBMS is the only product that may
provide such features, but currently, for an average enterprise
application, a RDBMS is the best availible product to provide these
features.
> Do you have any examples of relational databases that have specific features
> for non-persistent usage? All the relational databases I've looked at
> (again, a limited number) appear to put a lot of weight on the persistence
> aspect.
I just gave you four examples. If you are asking for a RDBMS product
that is suitable for all-in-RAM use, look at hsqldb.
>>> However, if you look around, I think you will see that the
>>> _vast_ majority of uses of databases are, in fact, for _persistent_
>>> storage of data.
>>Only in the OO world. In the rest of the world there are many examples
>>of the opposite.
> I'm open to be educated on the subject - please, could you point me at
> some examples?
If you look at enterprise applications outside the OO world, you will
find that they heavily use embedded SQL. Instead of loading the data
into memory structures, a select statement is used everytime some data
is needed. The RDBMS is configured to cache most of the data needed,
into memory. It means that the application asks the RDBMS for data that
resides in RAM. In this case, the persistence features is not involved
at all.
Another example is the use of transactions. This feature is not related
to persistence and enterprise applications uses them a lot.
> In my experience, even when I was developing procedural systems, in
> those systems, relational databases where used to work with persistent
> data. Transient data was generally stored in bespoke data structures in
> memory. This is without any OO involved.
This is true for some kind of applications, but normally not for
enterprise applications. Look at an old COBOL program. How advanced are
the data structures in COBOL? Almost the only thing you can do is to
traverse an array. All other kind of searched has to be done using a
select statement. Still COBOL was a very popular language, so the
concept with letting the DB take care of the collections handling was
not probably a very bad idea.
The concept with loading data into advanced structures instead of
making select calls, was originally caused by performance reason.
Currently I work with a scheduling application there I have to use this
concept. The result is bloated and messy code using TreeMap, HashMap,
ArrayList, etc, and I every minute I wish I could made a select
statement instead. But the time overhead with the interprocess
communications is simply too high. (One solution would indeed be to use
hsqldb as an all-in-RAM, in-process DB). But I strongly argue for just
using this this concept when performance reason force you to do. Using
select statements will give you much less bloated code.
Fredrik Bertilsson
http://butler.sourceforge.net
.
- Follow-Ups:
- Re: SQL
- From: Christian Brunschen
- Re: SQL
- References:
- Prev by Date: Re: SQL
- Next by Date: Re: SQL
- Previous by thread: Re: SQL
- Next by thread: Re: SQL
- Index(es):
Relevant Pages
|
