Re: Searching OO Associations with RDBMS Persistence Models


Dmitry A. Kazakov wrote:
On 1 Jun 2006 12:31:23 -0700, topmind wrote:

Dmitry A. Kazakov wrote:

Most communication systems have nothing to do with files.

Okay, byte streams? My point is that the transfer mechanism does not
need to care what the content is.

Exactly. For this you need something to describe and handle INTEGER as a
content. Is any content INTEGER? Is any INTEGER a content? This way you
come the notion of type and subtyping relationships between them.

We don't need types in databases. I use dynamic-typed and (almost)
type-free languages all the time. These don't need "types" from
databases. Only the type-anal languages like Java need them, and often
need wrappers/converters anyhow for lang-specific stuff, making
DB-types redundant or useless. DB types often don't map directly to
language types, so I say do away with them, or at least make them
optional like SqLite does. Anyhow, I don't want to get into another
language/variable typing debate here. I can refer to you a long and
winding debate of such if you really want to go there.


How is this any different? The
communication system simply sends stuff from point A to point B, it
does not have to care what the contents are (other than maybe virus
scanning). It is similar to how the mailman does not open your
envelopes.

That's the point. There is no word for "stuff" in your RM.

I think they are called "blobs" in current DB implementations.
(Something like, "Binary Large Objects").

Same question. Is INTEGER a Blob, when and how?

1. Procedural decomposition:
Let's define conversions:
To_Blob : INTEGER -> Blob
From_Blob : Blob -> INTEGER


In the case of data transmission, it is not the job of the transmission
engine to do the interpretation of the content. The letter carrier
handles your mail to you at the door or in your box and then walks
away.


2. OO subtyping decomposition:
Let's define a subtyping relation:
INTEGER is a subtype of Blob

3. RM decomposition?

3. Consider streaming a DVD movie, how big will be the table? Again, to be
stateless is a bad idea here. In a hierarchical decomposition state is an
implementation detail, hierarchy allows us to abstract it away, so that a
movie looks as if it were one value. But in RM it must be a 4GB value.

Are you saying that existing RDBMS have hard-limits on chunk size that
files don't have?

No, I mean that whatever data you have sent they become persistent. We
don't want this, for physical reasons. Consider a mobile phone as one of
the hosts.

The table can merely act as a buffer or staging area. The user device
can delete (or mark for delete) chunks that it is done with.

When it can do this? And describe this requirement as a relation, please.

As far as implementation, put a scheduled job to clean out any
"expired" records in case the player burped or crashed.


That is an implementation detail. If a RDBMS limits
chunk sizes, that is not because of relational theory, but [because] some
manager make some kind of implementation tradeoff or limit to speed
stuff up or cut costs.

I doubt anybody including you would buy a mobile phone with a RAID array
in...

I am not sure what your point is. Semi-relational DB's used to fit in
64k on CPM machines back in the early 80's. Wristwatches have better
processors than those CPM boxes these days.

Did anybody put voice content in there?

I don't know how voice apps were implemented back then. RDB's and their
cousins were probably too slow back then. However, I got great
performance out of Clipper on 286's.


Observe, that here again, we have ordered containers of unbound size
(tuples). The weakness of your model is that you don't have a type for
tuples. So you can't put them into cells. So even to implement something as
trivial as nslookup becomes a problem to you.

Again, why would the transport mechanism have to care about the nature
of the contents (other than the timing issues mentioned above)?

"It should not" is a decomposition of the problem "how I can handle all
kinds of messages without knowing them all." That is the very question.


Good question. Making it as parameter-driven (data-driven) as possible
so that new instances don't need new programming is one way. But what
raises a yellow flag is "kinds of" there. This kind of (pun) implies a
hierarchical taxonomy which I found to be a lousy classification and
variation management tool for real-world stuff and real-world changes
as I observe them. When real things change, they usually don't care if
they violate tree-ness or not. (Same with "flat" trees, which are
mutually-exclusive categories or sub-types.)



How would do you do an equivalent decomposition in your RM?

The transport system wouldn't have to do any "decomposition". It just
moves stuff from point A to point B and puts it back together again.
The using apps are what would have to "decompose" stuff. This is how
FTP, the internet, etc. does stuff. There may be a few protocol flags
in some cases (HTTP, HTTPS, MAILTO, FTP, etc.) I suppose you could call
these "types" if you really want to.


You are asking me to rework something that took many billions of
dollars to develop, into relational in a few days? What's next, a Nobel
Prize on the back of a napkin?

Yes, if you could. I think a novel approach to programming deserves Nobel
Prize much more than practicing terrorists and corrupt UN bureaucrats...

Well I did not invent relational. Perhaps I tried using it where it is
not commonly used (or at least not documented being used that way, as
much T.O.P. i've encountered is under the radar).


RM/Sets handle orthogonal traits and multiple viewpoints better than
trees. This is partly because any graph can be represented as sets, but
this does not hold for trees unless you duplicate nodes.

This is wrong. Any set can be represented as a Berge's graph, which is a
binary relation over a set of nodes: G:ExE->Boolean. It is trivial for any
given set A, to create a corresponding graph GA:AxA->True.

I don't see how this contradicts anything I've said. Trees are where
the limits are, not sets.


As I said before. Requirements are translated into a formal language. Once
I did it, I can find (or talk about) contradictions in the requirements.
Because I know that my language does not allow contradictions (=it is
consistent). So when I find (A & not A) in the translated requirements,
alarm starts to ring.

I think any implementation of the library requirements would run into
problems if the requirements are taken literally. Something that
validates that said catalogs are also in the catalogs will either crash
to get stuck in an infinite loop.

... and that to happen during landing on Mars? Thank you very much. I don't
need formalisms where True=>False.


Okay, if I ever build a machine to land on Mars, I will abandon sets
(to prevent whatever fear you have of them). Deal?


Let's not get
into shape battles anyhow. Shapes are not my domain so I don't care if
RM would trip over them. I never claimed that RM is good for all
domains.

But you claimed that nevertheless you have enough knowledge about shapes,
geometry and OO, to conclude that OO not only fails to model shapes, but
also, that this failure indicates fundamental flaw of OO, enough to discard
OO as a crap.

Have I correctly articulated your position?

I do not believe I mentioned the shape problems as proof, but merely as
food for thought.


No. I say that whatever model you propose, the librarian paradox should be
impossible to formulate in that model.

Then whether relational, types, or tinkertoys are used to model it, it
wouldn't matter.

Absolutely.

In other words, a personal preference. I prefer RM/sets over types the
vast majority of the time.


--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

-T-

.

Relevant Pages

  • Re: Searching OO Associations with RDBMS Persistence Models
    ... need to care what the content is. ... come the notion of type and subtyping relationships between them. ... OO subtyping decomposition: ... But you claimed that nevertheless you have enough knowledge about shapes, ...
    (comp.object)
  • Re: Searching OO Associations with RDBMS Persistence Models
    ... Procedural decomposition: ... I don't care if RM potentially stinks for systems software, ... (Same with "flat" trees, which are ... Back to the cat food versus human food ...
    (comp.object)
  • Re: The JBGI BS
    ... I have a different view and I don't care to convert anyone to using ... My wife plays flute. ... How in the world did Patricia incorporate your shapes on the ... we don't become a forum of professionals, ...
    (rec.music.makers.guitar.jazz)
  • Re: Searching OO Associations with RDBMS Persistence Models
    ... Procedural decomposition: ... "Scheduled job" is an object in an OO decomposition. ... why would the transport mechanism have to care about the nature ... (Same with "flat" trees, which are ...
    (comp.object)
  • Re: Chinese Dialects
    ... Why do you need to care about these ... All languages have a tendency to leave out ... Obvious examples, but not colorful. ... "You are here to learn the mysteries of Kung Fu, not linguistics. ...
    (sci.lang)
Loading