Re: too much OOP ?

On Thu, 3 Jan 2008 03:09:22 -0800 (PST), frebe wrote:

Currently one of the few sound theories to
backing up 4GL is relational algebra.

Huh, it was very unfortunate to all of us that RA was first used in 4GL. If
"relational people" did it in a 3GL with an elaborated types system then it
would have became just a decent part of mainstream OO.

I agree that mainstream SQL databases has a rather poor implementation
of RA. An open type system is very important for relational databases.
Unfortunately very few databases have it. But what stops "OO people"
from using RA in mainstream OO? If the "relational people" didn't do
it correct, we "OO people" still can.

Yes, but there is no urgent need in that. Within a types system RA of
objects is just an algebra, there are other algebras, neither better nor
worse. The application domain will tell. Another case is when RA were a
part of the algebra of types. That might turn very interesting.
Unfortunately types system issues are far beyond the horizon of the
practitioners. Also don't forget that there is no market of languages.
"Modern" languages are targeted merely as a tool for locking customers
in... (:-()

Every decent programming
language should have native support for RA.

Depends on the case.

1. RA of objects is a poor candidate to be native. I would leave that up to
the programmer. Especially because there could be different implementations
of RA meeting mutually contradicting requirements. Think of concurrency,
distribution, safety, real-time, run-time constraints etc aspects.

2. RA of types certainly deserves attention. There are difficult problems
with parallel types hierarchies and multiple dispatch. Maybe they could be
handled relationally.

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?

They should not consider the target platform, unless absolutely necessary.
Already the mindset "we use SQL database" is as wrong as "we use AMD
processor." Database is a part of hardware platform.

Who's mindset are you talking about, mine? Regardless the mindset, do
you think it is a mistake to use SQL databases in applications for
accounting, invoicing, inventory management, etc?

That depends on the functional and non-functional requirements of each
concrete system. The two basic ideas - of separation of data from semantics
(meaning) and of client-server architecture are ugly remnants of deep past.

Would it be better
to use some other kind of database instead or implement the data
management logic in the application instead?

If you can factor out these accounting etc as an abstraction, then do it. I
just don't see why it should be "database." Call it "accounting subsystem."
There is no "data management logic," there is only logic of "accounting."
This logic is implemented by the program. Who runs the program is of no
interest.

Nobody would ever propose a 4GL language for control (Simulink), or for 3D
simulation (OpenGL), or for 2D rendering (Postscript) as a paradigm. It is
only database- and maybe UML-people who have such strange idea. Others
quietly create their *libraries*. They might call them "engine",
"middleware", "framework", but show nothing alike that manic disorder the
former suffer... (:-))

(AMD is a vendor, SQL is a name of a family of databases or a
standard. It would be more correct to compare AMD to Oracle or DB/2.)

I meant AMD as a processor family.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: ID field as logical address
    ... If by "relational theory" you mean the relational algebra then it's ... This news group by definition concerns database theory. ... Imperative languages comprise ...
    (comp.databases.theory)
  • Re: ID field as logical address
    ... This news group by definition concerns database theory. ... Imperative languages comprise ... calculus or the algebra, ... SICP at the mit site, chapter three if I recall, talks about the sea change in comprehensibility that arises once assignment is introduced. ...
    (comp.databases.theory)
  • Re: A different definition of MINUS, Part 3
    ... can actually be the value of the database at any set point in time. ... updates, on the other hand, assert which possible value for the ... neither the algebra nor the calculus are sufficient when it comes to ... To extend the analogy to view updates, we also have an input delta ...
    (comp.databases.theory)
  • Re: a union is always a join!
    ... algebra, while necessary for describing database updates, is not ... database, not two successive databases. ... is not presupposed by either the relational calculus or the relational ... Regarding transactions and concurrency control 'belonging' to implementations, it is more that most people are blinded by past practice, failing to see that Codd's 'keys' might offer a theoretical way to describe those aspects. ...
    (comp.databases.theory)
  • Re: A different definition of MINUS, Part 3
    ... can actually be the value of the database at any set point in time. ... Algebraic expressions derive information from the actual value of the ... neither the algebra nor the calculus are sufficient when it comes to ... database updates. ...
    (comp.databases.theory)