Re: too much OOP ?

I have to remind you that you started to talk about abstraction
levels. You claimed SQL being at a extremly low level of abstraction.

No, I said that designing it in terms of records is low level. If the
application about customers etc, and people talk about records, then it is
low level.

I agree that record is a low-level construct, such as an struct in C
or class in C++. That is why the relational model doesn't has records,
like pre-relational databases.

The point is that when the language constructs are in terms of
records, while you can say "customer," in the language, then "customer" is
a higher level abstraction (relatively to the built-in language core), so
the design is.

So a relation named customer is a high-level construct?

If you had a language which could directly describe the
customer as a term, then that language would be low-level. It is all
relative.

Sorry, you lost me again... I think both Java and SQL are able to
directly describe customer as a term.

This is not a workable concept. The only way you could formalize it is by
considering some a target language and then measuring algorithmic
complexity of the language constructs.

And you still claim that MOV and UPDATE have the same algorithmic
complexity?

Yes. A primitive operation has alleged complexity 1. You can't look into,
it is dark in there...

So if any primitive in the language has complexity 1, how can
different languages ever have different complexity?

That was the reason why the 5GL project collapsed. Their primitive
operations could not be implemented uniformly efficient. SQL suffers this
problem too. Writing an application you have constantly to keep in mind the
implementation of the constructs you are using.

I agree with you to some extent. You need to consider physical indexes
when writing SQL queries operating on large amounts on data. But
having a query optimizer calculating the best execution plan is much
better than hard-code the execution plan in your application code.
Having to think of only some things in the implementation of the
constructs, is much better than actually having to implement the
constructs by yourself.

Bigger is n in nGL, more
attention you have to pay and increasingly difficult it becomes to foresee.
This breaks abstractions of the language constructs.

I can imagine the same discussion in the 60's, when 3GL was
introduced.

For 5GL it became just
catastrophic. We cannot go this way.

I think that when we get some sound theory backing up more 4GL or even
5GL, we will go this way. Currently one of the few sound theories to
backing up 4GL is relational algebra.

I have to ask you another question. In your first post, you claimed
SQL being low level. Now you seem to agree that SQL is high level
language. Instead you argue that too high level languages shouldn't be
used. Is this observation correct? Do you think that all developers
using SQL database are making a mistake? Would it be better if they
implemented the data management logic in their applications instead?
Or should they use some other kind of database?

I might add that SQL also have constructs for adding new bigger black
boxes. One is called views.

The OP meant UPDATE, not views.

Ever heard about updatable views?

Views is a step in right direction, away from climbing up the ladder to
hell.

Some things we could agree on anyway.

//frebe
.

Relevant Pages

  • Re: Full-Text Catalog does not build...
    ... You're welcome, Oleg, ... I've not confirmed if the Arabic language will be a FTS supported ... language in SQL Server 2005, you may want to review the ...
    (microsoft.public.sqlserver.fulltext)
  • Re: SQL
    ... Language can and do this. ... SQL is typed, ... How about something from the domain of custom biz apps. ... yet nobody would even try to use RDBMS for that. ...
    (comp.object)
  • Re: Databases as objects
    ... Isn't SQL able to assimilate to business vocabulary? ... using the same domain-ignorant language? ... Isn't the database schema already a domain-specific interface? ... have lesser lines of code than a corresponding assembler source code. ...
    (comp.object)
  • Re: SQL
    ... to have an ability to place things into cells ... It is a language issue then. ... An RDBMS engine that may ... Put a program code in a relational table and write compiler in SQL ...
    (comp.object)
  • Re: Full-Text Catalog does not build...
    ... You're welcome, Oleg, ... information as this is very useful in troubleshooting SQL FTS issues! ... language of US_English and with your column specific "Language for Word ... all of the *currently* supported languages in SQL Server 2005 for Full Text ...
    (microsoft.public.sqlserver.fulltext)