Re: Database Model - Class, objects and interaction



S Perryman wrote:
"topmind" <topmind@xxxxxxxxxxxxxxxx> wrote in message
news:566ed055-0bac-4cdd-90c3-173681cb7ea2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

S Perryman wrote:

F> And finally: Which of the criterias above disqualifies a relational
F> database as such system?

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

But this attribute-orientation is what allows relational data to be
readily *sharable* and query-able across *different* and diverse tools
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.


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.

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") without sending each and every detail record
to the client.



Behaviorism has less known math beyond it, at least as
far as managing the relationships *between* behavioral units.

Bit of a stupid statement.

Show some professionalism for once. Name-calling makes you sound like
yet another web asperger.

You are stating that there is more known maths for "behaviourism"
(whatever that actually means) than for "attribute-orientation" (what that
actually means) .


There are more known "maths" for manipulating relationships between
(properly defined) attributes than ADT's.

Bit of a stupid statement.
As the "maths" for manipulating relationships between ADTs is exactly the
same as for "attributes" .


No, because ADT's only let you do what the existing operators allow
you to do. 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. Further, I have to
push all 2-million items back onto the stack if I want to return it to
its former state.

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. After a while a
lightbulb will go on somebody's head, and they will standardize
collections and each automatically "inherits" filter, join, and
aggregation operations. Then they will realize they just reinvented a
database and go have a smoked Codd sandwich for lunch.


Thus, a sharable ADT repository that has database-like abilities is hard
to build.

Such repositories are indeed difficult to build.
But the reasons why have nothing to do with your argument (which is a
fallacy) .


The "self-handling noun" approach of encapsulation and ADT's makes it
difficult to factor together common verbs and common needs for
consistent manipulation. ADT's make very powerful independent little
machines, but they are not very social.

More meaningless rubbish.


This is a big philosophical sticking point. Attributism has its
downsides, but the up-sides outweigh them (at least in my domain).

See above.


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?


In my case, perhaps not the most efficient query engine that could be
produced, but not bad considering the very simple and small impl I
made to do the job.


Based on the way you communicate, I'm sure you think everything you do
is a Ferrari. Release your grand invention to the world and receive
the accolades for your brilliance that you deserve. (I feel queezy,
where's the barf bag?)


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.


Regards,
Steven Perryman

-T-
.

Relevant Pages

  • Re: Database Model - Class, objects and interaction [LONG]
    ... Information *interchange formats* are what make data readily shareable ... Let's revisit the ADT stack example. ... What requires that every "detail record" has to be sent to a client ?? ...
    (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: 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: 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)