Re: Searching OO Associations with RDBMS Persistence Models

Dmitry A. Kazakov wrote:
On 27 May 2006 23:39:45 -0700, topmind wrote:

Dmitry A. Kazakov wrote:

Which is completely irrelevant to A and B. Those are *requirements*. As for
design, no, you won't get that contract, just because of B, which reads:
"quality of service gradually influences the value of." If the system isn't
24-hours available you won't get a penny for it.

Centralization and reliability are not necessarily at odds. One can
have mirrored drives, realtime DB replication, etc.

Bingo! How are you going to replicate something without distribution? What
is the meaning of "replication"?

Perhaps we need to make a distinction here between distributed backups
and "live" distributed. Generally it is simpler to have one and only
one primary "live process". The mirroring to distance sites is for
emergancy purposes.

However, I suppose that the mirrored sites can serve as historical
research systems, such as a data warehouse kind of thing.


No. It looks like we will have a difficult time coming up with a mutual
example here. How about the airline reservation system mentioned.

Fine, write a communication protocol in *your* RM.

Again, I won't really defend RM outside my domain of expertise. (It can
probably be done, but I don't have enough experience in comm to do it
quickly here.)

You don't need any expertise, that's the point. If RM's decomposition
worked, you would just show how the problem relied on communication could
be decomposed and leave implementation to others. In other words, you would
identify "communication" component of the problem and describe it in the
solution space. This works with ADTs, it does not in your RM. Each time you
refer to predefined types, operations, stored procedures etc, it is an
*ADT* decomposition!

Please clarify. I am not sure what you are getting at here. RM is
generally not a "bahavioral" model, while ADT's are.


You are correct, I did not define typical or common set operators here.
But that is an implementation detail to be implemented with stored
procedures or app API's. I am not necessarily proposing that everything
be done thru SQL. (If we were using a more powerful query language,
then perhaps it could be intregrated.)

That is exactly the point. Your RM is too weak to be a viable paradigm.

Not doing the whole thing is not necessarily being "weak". It is a
matter of specialization, which is common in the human world. A
one-size-fits-all language or paradigm is perhaps an unrealistic dream.

No. See above. Specialization is a process of attuning something more
general. It is again the same question about decomposition. First, you need
to present a framework in which you can say: Y is a specialized X. Before
that there is no any specialization.

It is not a matter of creating or being subsets. A cook may be able to
serve resturant tables and a server may be able to cook, but generally
they specialize in larger restaurants. Specialization allows tools to
work where they work best. As mentioned above, RM is not an extensive
behavioral modelling tool and generally leaves that to other tools.


RM is a specialized ADT system, because I can identify the types (table,
column, row, cell) and exhaustively describe them. Types system is a
framework suitable to deal with any RM. The reverse is wrong. You *cannot*
specialize *your* RM to identify types, you cannot RM-decompose systems
that use such trivial things as communication protocols.

Again, being a subset or superset is not the issue. Having more rules
may make something technically a subset, but also results in more
consistent designs. Saying that A has more practical utility than B
because A is a superset of B is not a truism.

Goto's perhaps may be more generic than nested blocks in a programming
language. However, it is tough to work with them for most humans
because they offer no consistency.

Like I said, with a few tweaks, RM could be made Turing Complete and
could execute anything that any other programming language or tool
could. But, I question the practical utility of such.

Well, the default is not your position either. I don't see anywhere
where relational *must* be connected to types. Other than requiring at
least one "adaptor" to deliver boolean answers, relational does not
have to care what is in the "cells" of the tables. It mostly just
passes them along as-is or via the "domain math" operating on a real or
virtual row.

That's generic programming. A generic container does not care about the
types of its elements. This does not mean that the container itself can be
untyped. You have to specify which objects can be passed as-is. That
constitutes a type. Is a table of that type? In your RM it is obviously
not. So you have at least two types. q.e.d.

Perhaps. I agree that at the "root" level that a base set of
fundimental types may indeed be needed. However, to automatically
extrapolate this to "types everywhere" is bad reasoning.

Matching math to the real world is always going to be an imperfect
marriage because the real world is messier than math that tries to
model it the vast majority of times.

What do you have instead of mathematics? Knitting?

I am just saying that being tied to mathematical purity of concept is
no guarentee of being practical. You may argue it is a prerequisite,
but because there are many "math ways", a prerequisite is not a
guarentee.

I agree with that.

But the point is that to compare things like RM and OO you need a language,
and this language is mathematics. Statements like "this worked to me" have
no deductive prover.

Not all practical things are describable in a mathematical sense. And
being "nice" mathematically does not automatically translate into good
practical use. If that means we have to test it in a specific
programming language(s), then so be it.


So whether you like it or not, but you cannot make RM a paradigm without an
elaborated types system. I saw no RM proponent, except you, who would deny
this trivial fact.

If it is trivial, then let's see a trivial demonstration.

Just write a program that creates power set of a given set.

Not unless I see a practical and common need. "Your language is no
good because it takes to long too model Kline Bottles" is of little
practical use if that is not what one does with the tool.

You asked for a trivial demonstration. Then whatever I would take, you
could always answer that it is either non-trivial, non-biz or has no
practical use. Write an XML parser, invert matrix, make histogram of an
image, search kd-tree...

University lab toys are often not good tests for real-world utility.
It is not too much to ask for practical utility of something. And, I am
not familiar enough with systems software to make recommendations about
what is useful and what isn't. Thus, I am not sure what you are
complaining about.

As far as the Librarian Paradox, that seems like a problem with
conflicting/bad requirements. If your boss or users asks for something
contradictory, then you ask for clarification or a decision about which
of multiple paths to take.


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

-T-

.

Relevant Pages

  • Re: In the Matter of Herb Schildt: a Detailed Analysis of "C: The Complete Nonsense"
    ... world of mathematics the integers are a subset of the real numbers. ... When I used machine language, ... got assembler (later on in my first computer science class) I debugged ... types in programming languages differ from numbers as they exist ...
    (comp.lang.c)
  • Re: Overloading parentheses and type expectations
    ... the school mathematics. ... + does not mean the group operation of Z. Computers ... We could only be happy that guys "studying" programming languages have not ... but a suitably defined language allowing programmers ...
    (comp.lang.ada)
  • Re: Which computer language program is best for undergrads?
    ... the link between Haskell and mathematics. ... it if I want to try my hand at programming again? ... The book by Hutton is better for learning the language. ...
    (sci.math)
  • Guy Steele on Fortress, Java, and Fortran
    ... Steele has served on the Fortran standards ... "The Soul of a New Programming Language: ... extensively on mathematics. ...
    (comp.lang.fortran)
  • Re: object system...
    ... for that you need machine language. ... isn't even as fast as other systems programming languages. ... Stroustrup's stated design goal was to enable ... all manner of elegance or abstraction can be sacrificed for speed, ...
    (comp.object)