Re: OO vs. RDB challenge
From: Dmitry A. Kazakov (mailbox_at_dmitry-kazakov.de)
Date: 03/11/05
- Next message: Jason Hawryluk: "Re: OO vs. RDB challenge"
- Previous message: Alfredo Novoa: "Re: OO vs. RDB challenge"
- In reply to: Costin Cozianu: "Re: OO vs. RDB challenge"
- Next in thread: Costin Cozianu: "Re: OO vs. RDB challenge"
- Reply: Costin Cozianu: "Re: OO vs. RDB challenge"
- Reply: Daniel Parker: "Re: OO vs. RDB challenge"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 11 Mar 2005 22:16:13 +0100
On Fri, 11 Mar 2005 11:01:20 -0800, Costin Cozianu wrote:
> Dmitry A. Kazakov wrote:
>
>>>Make it Java + SQL or something
>>>equivalent and one can easily spawn processes for each user and perform
>>>the above actions by trivial SQL statements.
>>>
>>>1.a -- retrieving messages by a reader
>>> SELECT FROM messages WHERE group_id IN
>>> (SELECT group_id from r_groups_users where user_id= :user_id)
>>>2.a INSERT R_messages_users(msg_id,:user_id) VALUES (:msg_id, :user_id)
>>>2.b INSERT INTO messages VALUES (...)
>>>2.c INSERT INTO R_groups_users VALUES(:group_id, user_id)
>>>2.d DELETE FROM R_groups_users where group_id= :group_id AND user_id=
>>>:user_id
>>>2.e INSERT INTO groups values (...)
>>>2.f UPDATE users SET ... -- whatever profile values
>>>2.g INSERT INTO users VALUES (...)
>>>
>>>-- deleting groups without users
>>>3. Delete from groups g WHERE NOT EXISTS
>>> (select * from r_groups_users WHERE r.group_id= g.group_id)
>>>
>>>Having said that, the challenge becomes rather boring and unchallenging
>>>as there is no new insight to be gained from it. The host language will
>>>provide the source of random data, spawn threads, etc.
>>
>>
>> Are such trivial things impossible in the Great Relational Paradigm? No
>> pseudo-random generators? No any multi-tasking? I'm slightly disappointed.
>> (:-))
>
> Now I am sorry to say Dmitry but you are simply trolling.
>
> Who lead you to believe that the "Great Relational Paradigm" was good
> for writing pseudo-random generators ? It was certainly not me, and with
> your experience you should have known better. That's why such crappy
> arguments are a form of trolling.
So if we are in agreement that raw SQL does not qualify, then let me insist
that you have to present *complete* code.
To avoid further misunderstanding. That does not mean that you have to
present the source code of OS, Oracle or any library you are going to use.
It only means that you have to show a compilable code of the application
that solves the challenge and is linkable against the libraries you use. Is
that too much to ask for?
> It was *your* thesis that with such great advancements in RAM technology
> and OO and whatever, the SQL DBMS becomes a redundant element in the
> picture of a whole software system cause we don't need persistency no
> more, it'll be done automatically.
Correction, that was Robert Martin, but I fully agree with him. The notion
of persistency is a relict of the era when distributed systems were
considered as an unstructured bunch of hosts. In future systems nothing
will persist, but only exist.
> So I say fine, let's get persistence out of the picture, let's get SQL
> as well out of the picture, here's a problem, now solve it. At no point
> did I imply that the alternative to say an ADA only solution was a SQL
> onl solution. The current status-quo in a lot of systems is a
> combination of host-language + db driver + SQL DBMS, which proves good
> enough for tons of software out there.
>
> So your knoking down a SQL only solution is useless conversational chaff
I didn't require that.
>>>The SQL DBMS
>>>will perform the above data manipulation operations ensuring safety and
>>>consistency in the presence of concurrent access.
>>
>> You can't sell the above to a customer, can you? It should be a complete
>> executable application. If that includes a Sun cluster + Java + Oracle, let
>> it be so. (Though the customer might have some financial constraints, but
>> that's aside.)
>
> Non-sense. PostgreSQL and a Linux server with java or what have you
> will do just fine, these days.
Excellent, go on!
>>>In the meantime I have yet to see some OO code that solves even my very
>>>modest challenge.
>>
>> Your code is not yet a ready-to-use software. You have provided only a DB
>> structure. It is like a UML diagram, nice to have, but hard to sell...
>
> Well, I left the Java glue part as an exercise for the reader because it
> is trivial and boring, so it makes no sense to waste my time writing it
> in order to keep you happy.
It is no less trivial than to implement the challenge using any available
component library and either an OO language that directly supports
multitasking or one that uses OS primitives.
> So now let me see the OO code for my simple challenge. I contend that in
> the absence of a DBMS support to deal with issues of consistency and
> concurrency (as well as for other things like index bookkeeping), the OO
> code is anything but trivial. In fact it is seemingly so complex that
> nobody came close to approaching it, and even you try to handwave around it.
Not at all. The code in Ada 95 would be very simple and clean. Concurrency
is not an issue, a protected object solves that trivially. Consistency is
not an issue either, users and groups will be GC objects collected using
reference counting. The component library handles that. What else? Sets of
objects and two string maps? That is four instantiations from the same
library ten lines of the source code. Done.
Again I am ready to present the code if we agree on the details of the
challenge. But I insist that the code has to be complete and the result be
an executable ready to run.
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
- Next message: Jason Hawryluk: "Re: OO vs. RDB challenge"
- Previous message: Alfredo Novoa: "Re: OO vs. RDB challenge"
- In reply to: Costin Cozianu: "Re: OO vs. RDB challenge"
- Next in thread: Costin Cozianu: "Re: OO vs. RDB challenge"
- Reply: Costin Cozianu: "Re: OO vs. RDB challenge"
- Reply: Daniel Parker: "Re: OO vs. RDB challenge"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|