Re: Searching OO Associations with RDBMS Persistence Models

On 2006-05-30 22:47:04 -0500, frebe73@xxxxxxxxx said:

Disagree. There are COBOL programs that are 40 years old. There are C
and C++ programs that are 30 and 20 years old. There is no RDB program
that are older than about 20 years; and those wouldn't be compatible
with today's engines.
COBOL and C/C++ are examples of long-living programming languages. But
there are many examples of short-living languages, New Era, VB (before
.NET), PowerBuilder, Centura.

Ah, you mean DB languages. Yes, I agree those pesky DB language do tend to thrash a lot. (joke).

How long do you think Ruby, Python,
Groovy, etc will survive?

I expect Ruby and Python to be around as long as Perl.

How many years do you think it will take
until Microsoft once again force you to migrate your VB applications? I
happen to work with an system using five different programming
languages, four of them is now obsolete.

Bad choice of vendor. But your point is taken. Application language DO change. And when they do the cost is horrific. DB's also change. It would be nice if the cost of that change were NOT horrific.


And there's also a high degree of disparity driven by the fact that
each vendor wants to differentiate itself from the other.
What do you think is easiest: Migrate from RDB to Oracle or from
Centura to Java?

I WANT the cost of migrating to a new database to be close to zero.


At the level of the data structure elements. E.g. SQL knows about
integers, strings, dates, etc. It knows about tables and rows.
In what way is this different to C++. The primitive data types are the
same. Both SQL and C++ can be extended with custom data types. But the
data structure elements in C++ (structs, arrays, etc) are more
low-level than the data structures in SQL (tables, keys).

In C++, Java, Ruby, etc, you can build application objects that are semantic rather than syntactic. They are the objects that contain business rules.


It does not know about any application objects.
Obviously it is hard for the RDBMS to know about applications objects.
But that is irelevant regarding hig/low level.

Agreed. That's the point. Application objects, and the business rules they manage, are the domain of the application, not the DB.


No, what you'd implement in the RDB is the notion that a particular
string column would be unique. The RDB has no idea that this is the
name of the customer.
The applications doesn't have any idea either. Only humans has that
kind of capability.

Disagree. This can be semantically included into the application.


In the application objects the code would KNOW that the field was the
name of the customer and would ensure that it was unique semantically,
not syntactically.
AI has not yet come that far. That is the difference of being unique
semantically instead of unique syntactically? Either it is unique or
not.

It doesn't take AI to create a self consistent semantic network.


I didn't know line count was the metric! So "HLT" must be very high level.
Line count is almost the the only metric availible. Do you have another
metric to use?

It was a joke. Line count is not a good measure of whether something is high or low level. High level code can be in few or many lines. Low level code can be in few or many lines. The difference is not line count. The difference is in closeness to implementation detail or policy.

Or it might require a lot less code. Indeed, there are ways to
eliminate the RDB and relace it with virtual files that is
automatically persistent.
Can you show how the original problem
"select * from company where location=? and name like ?"
can be replace with less code using virtual files

No, I would use the SQL statement if I had an RDB. But I would hide the SQL statement from the rest of the application in an object whose job it was to query Company application objects.

That object could then be replaced with a completely differen object that used a completely different mechanism to query the company appliction objects, and the rest of the application would not know the difference.

The "virtual file" statement above was a reference to the idea that you can put all your data in RAM and use the VM system of the OS to keep the RAM persistent. Note that this is not a general recommendation, simply an observation that getting persistence that way costs virtually no lines of code at all. And, indeed, there are some applications for which this is a useful technique. Most, of course, need something a little more general and a little less fragile.


Or we could replace the RDB with an ODB that
takes very few lines of code to persist.
So, why is not everybody using a ODB? The failure of ODB are well
known. What make you think that it takes you more than a few lines of
code to "persist" something in a RDB?

I was saying 'or'. Actually I'm not a big fan of ODBs. I think they have some uses in isolated instances. Again, we were talking about line-count, so I was presenting some counter examples.


Or... The point is we are
not bound to a particular database implementation or scheme.
Now you are mixing two very different thing. Using ANSI SQL you are not
bound to any particular database implementation. But the database
scheme is part of the business rules and of course you need to be bound
to them.

True, but you are bound to SQL. (a scheme).


Sometimes the DATA is the heart of the system, but the
storage mechanisms is always a detail.
The programming language is also always a detail.

True. No argument. But there's no way to get rid of that detail. There IS a way to isolate the detail of the database.


The database is a detail to be decided at the last possible moment and
kept in a
position so flexible that it can be swapped out for another at a whim.
Why does the database need to be in a flexible position? Why does it
need to be swapped out at a whim?
It's called decoupling. It's one of those pesky principles of good
software development. The less you are coupled to detailed mechanisms
and implementations the better.
SQL is not a detail. Oracle/MySQL/SQL Servers are details, but it is
not very difficult to be decoupled from them using a subset of ANSI
SQL.

SQL is a detail at a certain level of the application. It would be a shame, for example, if we saw embedded SQL in the payroll calculator algorithms

C++/C#/Java are also details. Can you show me how to decouple from
them?

No. I believe that there is no way. The MDA folks do, but I think they are just creating another language which is a detail.

The point is that I CAN treat the DBMS, and even SQL, as a detail, and abstract it out of the rest of my application.

Conversely, the data modeler can abstract away the programming language. The data model does not need to admit that C++ is being used, or that any particular algorithm is being used to access the data.



--
Robert C. Martin (Uncle Bob)  | email: unclebob@xxxxxxxxxxxxxxxx
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |



.

Relevant Pages

  • Re: UDF returns table to feed a call back to itself ... how? (cross post)
    ... using SQL has his first ever programming language. ... Ever read Weinberg's PSYCHOLOGY OF COMUTER PROGRAMMING? ... I don't advocate scrubbing data with SQL. ...
    (microsoft.public.sqlserver.programming)
  • Re: The Lambda lambada...Why embedded SQL is becoming irrelevant and why you should start looking at
    ... approach as implemented by COBOL and other languages where we embed SQL. ... Functional programming represents the extension of the OO paradigm into ... "Intermediate Language" and, for the purposes of this discussion, can be ... Vista comes with DotNET ...
    (comp.lang.cobol)
  • Re: Searching OO Associations with RDBMS Persistence Models
    ... Both SQL and C++ can be extended with custom data types. ... The RDB has no idea that this is the ... not bound to a particular database implementation or scheme. ... The programming language is also always a detail. ...
    (comp.object)
  • Re: Alternative to Dynamic SQL?
    ... know any of that because you're a entry level programmer using ORMs ... who hardly know sql. ... People want to be able to write their application in ONE programming ... language - at least the core of that application. ...
    (microsoft.public.sqlserver.programming)
  • Re: DELETE rows from Table lists
    ... This is a sequential file model we used in tape systems in the 1950's -- ... hundred new SQL programmers in the next year. ... language a procedural language? ... How many years/months have your been programming in SQL? ...
    (microsoft.public.sqlserver.programming)