Re: Persistence
- From: "Alvin Ryder" <alvin321@xxxxxxxxxxx>
- Date: 13 Jul 2006 13:13:49 -0700
frebe73@xxxxxxxxx wrote:
If I get you right, when you talk about persistence, you don't talk
about transactions, consistency or queries. If you have such features
in your application, you use other tools or implements it by yourself?
Persistence is strictly about object IO. That doesn't mean I'd
implement the other stuff myself though.
So what does it mean? That you use other tools but a SQL database to
enable transactions, consistency and queries. Or that you don't use
other features but persistence?
Fredrick we seem to be going in circles here. I've already answered
what I take "persistence" to mean and I've already said if I'm using a
RDBMS I'll also use or at least seriously consider using other features
it provides. Doesn't that answer your question?
2. A SQL database provide many other features but persistence, but the
persistence feature is the only thing that should be used.
The relational model (RM) and RDBMS have strengths and features of
their own, which should not be overlooked.
Many features other than persistences features, or many persistence
features?
I meant the RM is built on solid foundations, not only predicate logic
and set theory but simplicity, data and logical independence and the
information principle just to mention a few. In addition RDBMS provide
concurrency, integrity management, security and lo and behold disk
storage ...
The conclusion is that you use a RDBMS for other things but
persistence?
Hmmm, I think more circles here. I use dbs for persistence and other
things.
The relational model was designed to work with any Turing complete
language, I don't see why an OOL can't be used.
Of course an OOPL can and should access a SQL database. The question is
whether
you should have persistent objects or not. OOPL may be used in many
ways.
If objects need persisting somehow and if I find it easy to use a db
then why not?
The relational model represents data in one and only one way, as a set
of tuples in relations where each tuple contains a set of attributes.
There is no direct support of object storage and subsequent
instantiation of objects from disk storage.
The relational model has nothing to do with disk storage.
I think the phrase "nothing to do with disk storage" is too strong. The
relational model was always meant to yield an alternative to the
prevailing data storage technologies of the time.
The relational model may be used for many purposes. Almost all database
implementations writes the data on disk, but there are also
implementations that don't.
That isn't the impression I got from reading Codd and Date's writings
but then again I suppose it was not disallowed either.
Codd's early papers like "A Relational Model of Data for Large Shared
Data Banks" make that abundantly clear. If "data banks" aren't what we
call databases stored on disk then what are they?
They may be tables that only exists in RAM.
Fair enough but you were saying the RM has "nothing to do with
storage", isn't that a bit of a stretch? If "large shared data banks"
are not what we call "databases" with data stored on disk then what are
they?
Fredrik Bertilsson
http://frebe.php0h.com
Cheers.
.
- References:
- Persistence
- From: frebe73
- Re: Persistence
- From: Alvin Ryder
- Re: Persistence
- From: frebe73
- Re: Persistence
- From: Alvin Ryder
- Re: Persistence
- From: frebe73
- Persistence
- Prev by Date: Re: Poly Couples
- Next by Date: Re: Observer pattern limitations
- Previous by thread: Re: Persistence
- Next by thread: Re: Persistence
- Index(es):
Relevant Pages
|