Re: OO vs. RDB challenge

• Previous message: Michal Kleczek: "Re: OO vs. RDB challenge"
• In reply to: frebe: "Re: OO vs. RDB challenge"
• Next in thread: frebe: "Re: OO vs. RDB challenge"
• Reply: frebe: "Re: OO vs. RDB challenge"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Tue, 29 Mar 2005 15:16:02 +0200

On 29 Mar 2005 03:32:55 -0800, frebe wrote:

>>f you say that there is no opposition between ADT and ADTs
>> describing relations, I will immediately agree.
>
> Of course not. ADT can be used to model tables, records, queries etc.
> But you need a backend RDBMS to provide the implementation, unless you
> want to build a RDBMS by yourself.

Why should I if there is a reusable code?

Example: you buy Windows XP to play say Splinter Cell. You are quite happy
not knowing that Windows activation system probably uses a giant DB.

>> And because relations too can be easily implemented as ADTs
>> there is absolutely no point in treating RDBMS as something
>> exceptional.
>
> I don't think it is easy to implement relations. Making a RDBMS is a
> lot of amount of work. If you talking about implementing a Table class
> that can be searched by primary key or by a full table scan, such
> implementation could be done in less than a day, but when you have only
> implemented a fragment of the relational model.

So what? It is a black box, I don't care what it in. That's the advantage
of ADT. It can hide either a RDBMS or a typing office as long as it
fulfills the contract, I don't need to look into.

>> RDBMS is an implementation issue, no more than that.
>> Therefore it makes a lot of sense to decouple it from the
>> application
>
> Correct, you don't need a RDBMS behind a JDBC/ODBC/ADO driver. It could
> be something much simpler, like a flat file system. But we need to
> agree what kind of interface we should have between the application and
> the database (or persistence mechanism).

We should clarify first. If you mean an interface for some reusable
container library then it is one thing. If you consider the interface as a
bridge between equal parties - the application and the DB - then it is
another thing. As I said before I don't buy separation of application and
data. So the only reason to have such protocol would be a legacy system...

> I think SQL (or something
> similar) is the best choice for many enterprise applications. You want
> low-level interfaces like Map and List.

I don't see how column, table, tuple are higher level ones. To me the
issues of concurrency, invariants and constraints are quite orthogonal.
Let's separate (1) queries (2) caching (3) concurrency and (4) relations.
1..3 is fully applicable to lists and maps. So what makes abstract
relations higher level than abstract maps? Surely not mathematics, because
there they are equivalent. Also what?

> That is probably the best
> choice for low-level applications like telecom switches and embedded
> control software, but for applications for logistics, production
> control, human resource administration, these kind of interfaces are
> too low-level.

The line is actually drawn between standard solutions to common primitive
problems and the solutions to be found. The application domain is of much
lesser importance because in practically any domain it is easy to formulate
a problem which would break any given solution.

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

• Previous message: Michal Kleczek: "Re: OO vs. RDB challenge"
• In reply to: frebe: "Re: OO vs. RDB challenge"
• Next in thread: frebe: "Re: OO vs. RDB challenge"
• Reply: frebe: "Re: OO vs. RDB challenge"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]