Re: Decline of Science: Computer Science and Databases

McKinley wrote:
> > Testing is a different beast. How thoroughly can you test that
> > an application will survive your SQL UPDATE statements?
>
> Until you find a system where "testing" is the same beast, you need to
> keep looking. Unless the DBMS and the application are one in the
> same, you are wasting time duplicating your efforts.

I fully agree that a system works best, if it is homogeneous.

Application programming mainstream is using Java or C#. Application data is stored in Java or C# objects. A system that can directly store and query Java and C# objects is bound to

- be the most efficient
- need the least implementation work
- have less errors

> If you would look at recent purifactions of the Relational Model you
> would know that an application would survive any "SQL" UPDATE
> statement because the application and the developer applying wild
> statements to the DBMS have to use the same integrity constraints.

Constraints can never heal application errors completely. If the application looses one character while encrypting the password string, no constraint logic can correct the error.

Constraints fail to solve the simplest protection tasks. How would you protect your database from: UPDATE PERSON SET NAME = 'Haha funny';
...that's the sort of nice errors that can happen, if someone forgets to add a where clause.

It is very well possible to work with integrity constraints in a pure object oriented system. All you need is a framework that checks constraints every time an object is to be stored, modified or deleted.

A simple example:

public class ObjectOrientedConstraintLogicForMcKinley{

  String firstName;
  String lastName;
  int age;

  public boolean[] constraints(){
    return new boolean[]{

      firstName != null,
      lastName != null,
      age >= 0,
      age <= 130

> That is the big deal, the news. Look into the true Relational Model
> and understand how to stop writing logic, constraints, validations,
> etc. at the application level. Also, learn how to stop writing stored
> procedures, triggers, id generators, etc. at the database level. It
> is all happen at the datatype and operator level. Relational algebra
> and predicate logic are better than OO.

Your statement is wrong by definition:
The term "better" never makes sense without a "for what".

A question I have posted here before:
What is Chris Date's team using to program Alphora Dataphor? Relational algebra?
I think they are using C#, an object-oriented language.

Object oriented programming languages are supersets of relational algebra, since you can build relational algebra with them.

I fully agree that it may be a good idea to introduce an abstraction layer between application objects and stored objects, to be able to operate with different logic on the same data. You are free to decide, what makes more sense:
(1) mapping objects to objects
(2) mapping objects to tables, "domains", whatever

I also agree that it may be helpful to query stored objects in a way that was not pre-designed by OO-logic. Why not with relational algebra?

Kind regards,
Carl

--
Carl Rosenberger
db4o - database for objects - http://www.db4o.com