Re: SQL

H. S. Lahman wrote:
> >>SQL represents a
> >>solution to persistence access that is designed around a particular
> >>model of persistence itself.
> > Since when is the relational model a "model of persistence". Can you
> > provide any pointer showing that the relational model is supposed to be
> > a "persistence model".
> I didn't say that. The RDM is a model of static data so it can be
> applied to UML Class Diagrams as well. Note that I was careful to say
> that SQL is a solution to persistence /access/ when the data is
> represented in RDB form. As you have pointed out elsewhere one could
> create a RAM-based RDB and use SQL to access it with no persistence.

You agree that the relational model is not only about persistence? But
why is the SQL language limited to only the persistence features of the
relational model?

> >>Try using SQL vs. flat files if you think it is independent of the
> >>actual storage mechanism. (Actually, you probably could if the flat
> >>files happened to be normalized to the RDM, but the SQL engine would be
> >>a doozy and would have to be tailored locally to the files.) SQL
> >>implements the RDB view of persistence and only the RDB view.
> > Yes, the files need to be normalized to the RDM but why do you make the
> > conclusion that SQL needs a RDB?
> SQL requires the data to be in tables and tuples with embedded identity.

SQL does not requires the data to be in tables. The data may reside in
flat files or RAM structures. Just because the SQL language uses the
keyword "table" does not actually mean that it need to be backed up by
a physical table. SQL is an interface, remember?

> The RDM, when applied in a broader context than Codd, does not require
> that. SQL also assumes a very specific paradigm for navigating table
> relationships.

I think you are trying to hijack relational theory here. Do you have
any pointers to this second definition of relational theory?

Fredrik Bertilsson
http://butler.sourceforge.net

.

Relevant Pages

  • Re: SQL
    ... persistence to RDBs in the computing space. ... SQL has already made that implementation choice. ... purpose access to persistence, much less general computing. ... implements the RDB view of persistence and only the RDB view. ...
    (comp.object)
  • Re: Encapsulation vs separation of concerns
    ... SQL abstracts the RDM in text form and hides the actual implementation ... of the RDB and even the RDB engine API. ... So it can't be used if persistence isn't ... those enhancements, then the SQL itself is not portable even between RDB ...
    (comp.object)
  • Re: SQL
    ... solution to persistence access that is designed around a particular model of persistence itself. ... provide any pointer showing that the relational model is supposed to be a "persistence model". ... Note that I was careful to say that SQL is a solution to persistence /access/ when the data is represented in RDB form. ...
    (comp.object)
  • Re: SQL
    ... Java is a specific implementation of a 3GL. ... > abstraction, SQL is an implementation. ... > solution to persistence access that is designed around a particular ... > implements the RDB view of persistence and only the RDB view. ...
    (comp.object)
  • Re: SQL
    ... >>>abstraction, SQL is an implementation. ... counts, averages, etc.) Mere persistence does NOT have to include ... >>>specious because Java is a general purpose 3GL. ... Good apps don't need a one-size-fits-all language because they can use ...
    (comp.object)