From: Patrick May on
frebe73(a)gmail.com writes:
>> 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,

I might, because it _is_.

> but the relational model separates logical data from physical
> data. A lot of different data structures might be useful as indexes.

You're emphasizing your contradiction by admitting again that
relations are _not_ the only data structure necessary.

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

Are you asserting that only relational databases require data
structures other than relations?

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

That's simply repeating yourself. You haven't proven your
assertion and, in fact, you've contradicted it on several occasions.

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)
From: frebe73 on
> If you can't prove it, retract it and stop making such claims.

Don't you realize that you and RCM had made a number of claims in this
thread, without proving them?

/Fredrik
http://mybase.sf.net

From: Patrick May on
frebe73(a)gmail.com writes:
>> If you can't prove it, retract it and stop making such claims.
>
> Don't you realize that you and RCM had made a number of claims in
> this thread, without proving them?

You be sure to point them out and I'll address any I made, right
after you provide some solid support for your claim that relations are
the only data structure that should ever be used.

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)
From: frebe73 on
> >> If you can't prove it, retract it and stop making such claims.
>
> > Don't you realize that you and RCM had made a number of claims in
> > this thread, without proving them?
>
> You be sure to point them out and I'll address any I made, right
> after you provide some solid support for your claim that relations are
> the only data structure that should ever be used.

You can start with this one:
"The database schema and the application logic change for different
reasons. Decoupling the two minimizes the impact of those
changes."

Fredrik
http://mybase.sf.net

From: Patrick May on
frebe73(a)gmail.com writes:
>> >> If you can't prove it, retract it and stop making such claims.
>>
>> > Don't you realize that you and RCM had made a number of claims in
>> > this thread, without proving them?
>>
>> You be sure to point them out and I'll address any I made,
>> right after you provide some solid support for your claim that
>> relations are the only data structure that should ever be used.
>
> You can start with this one:
> "The database schema and the application logic change for different
> reasons. Decoupling the two minimizes the impact of those changes."

Nice, an easy one. As I said, I'll get right on it just as soon
as you provide some solid support for your ridiculous assertion that
relations are the only data structure that should ever be used.

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)