Re: Searching OO Associations with RDBMS Persistence Models

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. How long do you think Ruby, Python,
Groovy, etc will survive? 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.

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?

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).

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.

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.

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.

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?

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

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?

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.

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.

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.

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

Fredrik Bertilsson
http://frebe.php0h.com

.

Relevant Pages

  • Re: Searching OO Associations with RDBMS Persistence Models
    ... I agree those pesky DB language do tend to thrash a lot. ... Both SQL and C++ can be extended with custom data types. ... The RDB has no idea that this is the ... The programming language is also always a detail. ...
    (comp.object)
  • Re: dbdebunk Quote of Week comment
    ... But SQL does not have a pointer data type or the mechanisms to handle pointer operators, garbage collection and housekeeping, so 20+ years ago the original Sybase SQL Server exposed an integer that can map back to the contiguous storage model used under the covers. ... More and more programmers who have absolutely no database training are ... Most of them simply start programming SQL as if it were their native ... But why is little Cindy Lou Who employee ...
    (comp.databases.theory)
  • 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: Mildly OT: dBASE IV
    ... I was interested to see item #5: dBASE IV. ... That product by the way was Foxpro. ... I had been programming for some 20 years, as a student, in on campus summer ... released internal copies of DEC Rdb. ...
    (comp.databases.theory)
  • Re:Job interviews
    ... 2 Years SQL and Or Oracle and familiarity with Crystal ... tool names has little to do with programming modules using SQL Server), ... discussion of technical knowledge in a core area in which you are looking to ... enough relevance on core issues which the interviewee must know to do the ...
    (microsoft.public.dotnet.languages.csharp)