From: frebe73 on
> You said "we can limit ourself to these structures." That is
> simply not the case.

You asked me to show the benefits of relations compared to other data
structures, and in my response I limited my comparison to the two most
common structures. But as I said, you are free to discuss any other
kind of structure if you want to.

> > You may pick any data structure and show the benefits compared to
> > relational algebra.
>
> Nice try, but you made the claim that "Relations is the only data
> structures that should be used." The burden of proof is on you.

I showed the some of the benefits with relations compared to lists and
maps. If you want to we may discuss any other data structure.

> Of course, you've already contradicted yourself by admitting that other
> data structures are required to implement, for example, a relational
> database.

You might consider that an contradition, but the relational model
separates logical data from physical data. A lot of different data
structures might be useful as indexes. But if you have a relational
database availible, you don't have to work with the low-level
structures. Somebody else did the work for you.

> >> I've been in the industry for close to twenty years and started out
> >> working on a CASE tool that supported all the common relational
> >> modeling techniques at the time. Nice try with the condescension,
> >> though. It's easier than actually defending your ridiculously
> >> broad claims, isn't it?
>
> > What is your point? CASE tools are flawed? The relational model is
> > flawed?
>
> My point is that your attempt to use snide comments to deflect
> from your own inability to defend your claims has failed.

I still not understand your point, but I probably never will.

> Now, if you're saying that
> other data structures should be used, I agree. That refutes (again)
> your original claim that "Relations is the only data structures that
> should be used."

I don't know if it would make you happier, but I could refrase my
statement to:
"If you have a relational database availible, with satisfactory
performance, that is the only data structure you need".

/Fredrik
http://mybase.sf.net

From: frebe73 on
> >> 2. Both sides can be tested independently of the other.
>
> > I don't understand why OO people insits testing their application
> > without the database.
>
> Because it's faster.

Really? You don't need to restore a 5Gb database every time you set up
a test case.

> Because we can control the data more easily.

By testing the application without the database, you can control the
data more easily?

> Because the tests can be kept independent (no accumulation of data from
> one test to the next.)

You may rollback the transaction after the test. Doesn't the same
problem exists for a objects? The relations or objects need to be
reset to a given state before the test starts.

> Because we can run the tests on our local laptops without a database.

Didn't we already agree that this was a silly reason?

> Because we can run the tests before we have chosen a database.

What are the reason you can't choose a database before you start
coding?

> Because we can simulate *any* kind of malfunction.

Even with emedded SQL statements, all database calls pass some kind of
API, like JDBC, etc. Simulating malfunctions would be easy anyway.

> I could go on...

Please do.

/Fredrik
http://mybase.sf.net

From: frebe73 on
> > Are really test performance a factor that should have impact on how to
> > design software?
>
> Absolutely! Test performance is critical to software design. If tests
> are slow, they simply don't get run often enough. If tests are fast,
> they can be run every few minutes.

Do they really need to run every few minutes? Wouldn't every hours or
for some test cases every day, be enough? What about the database
code, don't you need to test that code often too?

/Fredrik
http://mybase.sf.net

From: AndyW on
On 1 Feb 2007 09:17:59 -0800, "topmind" <topmind(a)technologist.com>
wrote:

>
>AndyW wrote:
>
>> That bit of code would be a lot simpler and execute much faster if it
>> was written in COBOL.
>
>I am not sure if this was meant as a joke or not.
>
Not really, that example is a simple case of working thru an ordered
list and performing an action. COBOL is in my mind really good at
doing that.

Andy
From: Patrick May on
"topmind" <topmind(a)technologist.com> writes:
> Patrick May wrote:
>> >> Second, you haven't shown that a solution that "embraced the DB"
>> >> would be shorter, more understandable, more maintainable, more
>> >> extensible, more easily testable, or "simpler" by any other
>> >> metric.
>> >
>> > I don't claim I can show it objectively better.
>>
>> Actually, you did. Your exact words were: "If you embraced
>> the DB instead of spend all your code wrapping it, the app would be
>> noticably simpler." That's a positive claim about an objective
>> measurement.
>
> I was talking about Martin's payroll example.

Yes, I've been following along.

> In that case I am pretty sure my version would be noticably simpler.

Yes, that's that positive claim again. Prove it.

> However, I doubt many OO fans will agree that Martin's code is the
> best or simplest OO can be.

Immaterial. His code has one significant advantage over yours:
existence.

>> > It just won't be objectively worse.
>>
>> That's another positive claim. Prove it.
>
> Let me reword it: Nobody can/will prove it objectively worse.

That's not a rewording, that's an attempt to squirm out of your
burden of proof.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)