Re: OO vs. RDB challenge
From: Alfredo Novoa (alfredo_novoa_at_hotmail.com)
Date: 03/24/05
- Next message: Alfredo Novoa: "Re: OO vs. RDB challenge"
- Previous message: Mark Nicholls: "Re: Attaching a behavior only to multiple classes."
- In reply to: kurbylogic_at_hotmail.com: "Re: OO vs. RDB challenge"
- Next in thread: Michal Kleczek: "Re: OO vs. RDB challenge"
- Reply: Michal Kleczek: "Re: OO vs. RDB challenge"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 24 Mar 2005 04:47:58 -0800
"kurbylogic@hotmail.com" <kurbylogic@hotmail.com> wrote in message news:<1111488976.454766.187380@o13g2000cwo.googlegroups.com>...
> The point I wanted to make is that one should choose the correct tool
> for the correct task...
And OO is not the correct tool for data management.
> in OO the
> complexity of mapping database tables to objects is useful only if the
> object has behavior,
An object always has behavior.
> such as Loan.Approve() that involves more then
> just updating a field.
It would be a lot better to do this:
update Loans set Approved = true where Id = ...
The Loan class and the Approve() method are superfluous.
> If all you want to do is create a list of users
> and groups and maintain some relationship between them then an OO
> solution has little value
Like in any data management scenario.
> and given the choice between a database or OO
> solution to the problem I too would use the database,
You would use the DBMS.
> nearly every
> application I write anymore involves a database as part of the
> solution, but a database alone cannot provide a complete end-to-end
> solution.
It is clear that when you say database you mean DBMS, and a DBMS might
provide a complete end-to-end solution.
> The database might be "thread-safe" but thread-saftey does not prevent
> data in all cases from becoming inconsistant.
Of course!
What a silly statement!
> It is not thread-saftey alone that ensures data
> concistancy, it must be coupled with issolation, issolation is the
> easiest and probably most common OO approach to concurrency issues in
> object solutions
But such isolation does not work with shared data sources.
> all. This is not true with the database where inserts that have not
> yet commited can be seen by other or users
Only whether you are using the "dirty-reads" "isolation" level.
That does not happen with the default configuration (read commited) of
any SQL-DBMS.
> So in response to your initial challenge, the following addresses ONLY
> your solution as you insist and is thread safe (policy class does not
> need to be thread safe because a thread can only get an instance of it
> via new Policy()
Astonishing!
So what about the other threads?
> or from the SecurityManager which returns a new
> instance with a copy of the current state therefore it is issolated
> from other threads and does not require any locking)
So it is thread safe because it does not support multi-threading.
Great!
> You refuse to add any more complexity to this task, yet bring up yet
> bring up "deadlock detection" which isn't even remotely necessary in a
> solution that requires no locks.
This problem requires locks.
> It is only slightly longer than your table creation script, but you did
> not include any procedure creation scripts
What procedures?
It is not necessary to write any procedure to solve this problem.
>therefore I assume that you
> must expect the client to query the user/group tables directly...
Of course!
So what!
That's the way to work with an SQL DBMS.
> If/When we decied to add groups into groups all changes are issolated
> to the policy class, you would have to update all of your "only one
> statement..." in dozens if not hundreds of locations
Plain nonsense.
> Relational databases aren't going away, but not because they are less
> complex.
Nonsense.
> I guess you can call SQL is a "high-level" language, its
> purpose is however different, it is a set oriented language it works
> well with sets of structured data
Data is structured by definition.
>, OO languages provide polymorphic
> behavior which you deny even exists,
He meant that this is meaningless pap.
> So if you are going to complain an
> many-many relationship in OO is *too complex* (which of the 35 lines
> was complex?) then abandon OO write all your business logic in in SQL,
Many peoply write all their business logic in SQL!
But OO still might be useful for the presentation logic!
> why can't I say load the current state of the
> system without having to reconstruct object graphs from dozens of
> seperate tables.
You can, but that is a blunder.
> If persistance was the only useful service provided
> by a relational database then I suppose more persistant memory is all
> one would need. But obviously you are not interested in the
> big-picture just the overwelming complexity in the 35 lines of code to
> implement a many-many user group relationship.
Where do you want to go with this?
> Someone who does not see value in an OO language either because he
> refuses to or cannot face the inevitable complexity of any real
> application
The complexity of your broken code can be avoided with a DBMS, and it
would work.
>, or because the "complexity" of a many-many relationship is
> too much to handle
It seems that it is too much for you, but it is absolutely trivial
using an RDBMS.
>, than I couldn't possible expect him to see any
> value in an object database either.
That's really funny.
Do you mean the utterly discredited OODBMS's of the 90's?
Regards
- Next message: Alfredo Novoa: "Re: OO vs. RDB challenge"
- Previous message: Mark Nicholls: "Re: Attaching a behavior only to multiple classes."
- In reply to: kurbylogic_at_hotmail.com: "Re: OO vs. RDB challenge"
- Next in thread: Michal Kleczek: "Re: OO vs. RDB challenge"
- Reply: Michal Kleczek: "Re: OO vs. RDB challenge"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
