Re: Database Model - Class, objects and interaction [LONG]



S Perryman wrote:
"topmind" <topmind@xxxxxxxxxxxxxxxx> wrote in message
news:12665498-b541-4ced-9698-8bb3c63ccb23@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

S Perryman wrote:

SP> A Relational data *value* base (the typical SQL products like Oracle
etc)
SP> could not be a general OODB, because you cannot provide user-defined
SP> ADTs whose properties are complex computational processes, not mere
SP> data values.

TM> But this attribute-orientation is what allows relational data to be
TM> readily *sharable* and query-able across *different* and diverse tools
TM> and languages.

Rubbish.
Information *interchange formats* are what make data readily shareable
across "different" and diverse tools/languages.

But they don't deal with behavior well, especially ad-hoc queries
involving lots of inter-relations.

You really do have an incredibly poor understanding of written English.

What does :

<quote>
Information *interchange formats* are what make data readily shareable
across "different" and diverse tools/languages.
</quote>

have to do with "behaviour" , "ad-hoc queries" , "inter-relations" etc ??

Nothing.
Information interchange is to do with information interchange.

It sounds like there's some communications confusion here. Even a
function call within a program can be called an "information
interchange".

No difference on that front between SQL and XML, ASN.1 ( <insert your
favourite info interchange format here> ) ...

XML does not by itself define the base operations. It's merely a
syntactical convention. It can be everything or nothing.

XML is an information interchange convention. Nothing else.


An example of ad-hoc ADT queries would be helpful. How about something
that shows the equivalent of joins, predicate filtering, and
aggregation ("group by")

The syntax of such expressions will be prog lang specific, will it not.

So the best we can do is to suggest you tell us which prog lang you feel
comfortable reading/understanding, and we can quickly search for some
lit source should enable you to see/understand how the expressions would
be constructed.


Let's revisit the ADT stack example. How can I effectively get a list
of all green nodes from a stack that happens to have a billion nodes?
First I want a count of the green nodes before I actually retrieve
them to make sure I don't get too much. For the sake of the example,
suppose each node has three attributes: name, color, and price. Also
assume a client/server-style setup where we are not actually at the
computer with the stack contents.


without sending each and every detail record to the client.

What requires that every "detail record" has to be sent to a client ??


I will answer that after we finish the stack example.

If those operations don't allow things like joins,
aggregation, and predicate filtering, then you are SOL without loading
a raw dump into some other tool.

Let's start with something simple. Suppose I am using an ADT-based
stack remotely (client/server). I can push and pop one item at a time.
But, what if I want to find all green items in the stack and the stack
has 2 million items? If its a remote service, I'd have to pop all 2
million items and send them back to me (client) one at a time.
It's not only slow and inefficient bandwidth-wise, but the client side
still has to do all the searching/filtering work.

Exactly the same problem with a database system where the query engine
is at the client side, and the data elements are not.

No, it is NOT the same problem because you added a situation that
makes both sides tough. Perhaps that situation is a wash, but that is
NOT the situation I am addressing. If ADT's are competitive with
RDBMS, then you shouldn't have to change the scenario to handicap the
DB, right?


So this is a fallacy.


Further, I have to push all 2-million items back onto the stack if I
want to return it to its former state.

Depends on your implementation of the stack.

If the pop op is returning a new stack (basic applicative programming -
I am assuming an understanding here of basic CS concepts like
applicative programming) , then what you describe is a fallacy.

Again, you are reworking the "stack" to try to get around the problem.
Assume a basic stack that returns a single node per pop. In our
example, it would be a record (map) with 3 items: name, color, and
price.



Sure, we could add filter, join, and aggregation to the stack
operations to give us such services. But we'd have to do this to each
and every ADT if we want these common services.

At last, something that is not fallacy.

For collection types, you will indeed need the means to provide
at least one of the fundamental FO predicate logic constructs (forall,
exists) .

Sure, the more DB-like features you add to each and every ADT, the
more they become like a database. That should be obvious. (Although
working together well from a performance standpoint may be tricky.
Uniformity of implementation is usually needed for such integrated
efficiency.)



After a while a lightbulb will go on somebody's head

For some, the light is on at the beginning.


and they will standardize collections

It never happens like that.
Standardisation happens for *specific* prog langs (the STL in C++ ,
the collections packages in Java etc, the Base libs in Eiffel etc) .

However there is a consensus as to what capabilities collection
frameworks should have. The commonalities far outnumber the
differences.

Yes, but ADT's don't automatically come with them. Plus, it may be
poor labor factoring (redundancy) for each and every ADT to reinvent
the implementation of the common collection-oriented verbs.

It makes sense to look at all this redundancy and say, "hey, maybe we
can somehow factor this effort together so that we don't have to
reinvent the wheel for each and every ADT"?

Guess what such a tool would be called?



Then they will realize they just reinvented a
database and go have a smoked Codd sandwich for lunch.

No, they have provided the means to execute relational expressions on
collections of ADTs.


You have not demonstrated that's is both possible and relatively
efficient for client/server environments.


TM> How would one go about building an ADT-centric database???

1. I have built one. So have others. How about you ??

Let's see the docs. Why hide your magic candle under a bushel?

Actually the system implementation is the IPR of a major telecoms company
(they may have actually patented it - they were certainly gathering
particular
stuff from that project for patent application) .

The basic premise is this. Given object type classifications such as :

Let's finish the stack example first, if you don't mind. Readers don't
want a telecom industry lesson just yet.

2. In general, the technology exists and has been proven, for decades.

And if you actually understand what is required (clue: the "less known
math" ) , what a fool you will show yourself to be (LOL) .

Claims claims claims.

You haven't a clue as to how a relational ADT base could be implemented,
have you ??

I didn't claim they were great nor possible, thus the burden is not on
me to show how its done.


You are ignorant of even the most basic concepts, and issues. Fact fact
fact.

Good, then kick my sorry ess with the stack ADT example. Hit me with
your best shot, Smarty. Show you are smart instead of claim it.
Everybody on the goddam web thinks they are Einstein. Claims are cheap
to come by.

Regards,
Steven Perryman

-T-
.

Relevant Pages

  • Re: Database Model - Class, objects and interaction
    ... aggregation, and predicate filtering, then you are SOL without loading ... what if I want to find all green items in the stack and the stack ... million items and send them back to me (client) one at a time. ...
    (comp.object)
  • Re: Tell, Dont Ask
    ... That is, when Stack::empty returns TRUE, then the client needs to do something other than processing an element. ... we can deal with that by having Stack::pop return NULL if the Stack is empty. ... Sure the invariant will be kept, but not because of any effort on the part of the Range class, users of Range are the ones that have to make sure the invariant holds... ... this approach fails when something else in the overall solution context says that the client really never should supply a value less than the current self.low. ...
    (comp.object)
  • Re: ObjectInputStream$HandleTable$HandleList
    ... > After a few thousand objects, the client experiences a java.stack overflow. ... > causing the stack overflow. ... > instance count at 143579 before the stack overflow. ... If the heap gets too large, shouldn't it throw a outOfMemory error? ...
    (comp.lang.java.programmer)
  • Re: Tell, Dont Ask
    ... that client already needs to be prepared for the stack being empty. ... That is, when Stack::empty returns TRUE, then the client needs to do ... def getHigh: ... Sure the invariant will be kept, but not because of any effort on the ...
    (comp.object)
  • Re: ADTs
    ... cases (my definition of an ADT seems fuzzier than yours, ... > are very useful concepts that most programmers are familiar with. ... for a useful stack. ... *something* seems to me very much part of their abstraction. ...
    (comp.programming)