Re: SQL


Dmitry A. Kazakov wrote:
On 6 Feb 2006 19:32:11 -0800, topmind wrote:

Dmitry A. Kazakov wrote:


Huh, the code you presented is 1) longer, 2) far more confused.

I don't have to define and hunt down definitions of types. You will
have something like:

a = new integer(min=-223452345, max=234234234);
b = new integer(min=-09809809809, max=242093423423);
x = a.add(b);

type I is new Integer; -- Compare with CREATE TABLE statement
A, B, X : Integer;
X := A + B;

The context was "configurable" integers. You are using the
out-of-the-box 8-byte version here, not configurable ones.

And, I never was a fond of SQL "Create" command syntax anyhow. SQL is
NOT the pinnacle of relational languages by any stretch.


As I have shown, it is not type free. It is typed in a definite way.

I suspect we would need a clear definition of "types" to settle this.
Either way, it is not relying on "types" in the usual strong-typed way.
By the way, many scripting languages make no internal distinction
between:

x = 123

and

x = "123"

and "1 23"? Type is a set of values and operations. It is irrelevant how
you denote values!

Thats my point.


Rounding errors for "add"?

Add 1.0 to 1000000000.0 in IEEE 32-bit and print the result. That should be
the very first thing students should do in classes. This is why different
numeric models exist. There is a trade-off space, performance, accuracy,
set of closed operations. It isn't rocket science...

Floating point tends to stink for biz apps, where decimal arithmetic is
preferred over converted binary. But, that is another topic. (Although
I've nevered encountered floating point problems during adds IIRC.)


Fine, show us an outline of a better language limited to solely relations
and we'll see.

Hold on, are we talking about implementation here, or the language? I
don't see how the language relates to compactly representing pixels
internally.

Of course it relates. I want to access each pixel relationally, using
SELECT. How would you implement, say, motion detection in video images if
you cannot access pixels? You say you are thinking in tables. Please, do it
this way!


I would have to think a while about how to implement motion detection
algorithms mostly with relational operations. I'm rusty on such
problems even using sequential logic, not having worked on those since
waaaay back in my college days.

Why are you selecting "science lab" kinds of problems anyhow? Maybe
relational does suck with science-lab kinds of problems. It is not my
domain and I don't really care. It is one domain out of many.


Please clarify. Relational does not limit auto-generated keys. Some say
it "encourages" one to use domain keys, but this has never been
settled, and some argue that auto-gen keys are or can be domain keys.

Auto-generated keys defeat the model. It is a work-around.

Hogwash.

Is uniqueness a
property of a table, row, cell, value, DB, Universe?

If it is needed by the domain, then relational does not care. As long
as a table defines a unique key, relational is happy. Whether that key
is an auto-gen number or the square of the pimple count on your pet
girbles, it ain't care.

Can I copy it? Is the
copy unique again? In which scope? Can I add such keys? Sort them? These
questions have many contradicting answers. Sometimes I need one answer,
sometimes other. ADT solves that by having clear contracts of the objects
in use.

Show me! OO has a horrible time with usable identity, with no built-in
referential tools whatsoever, leading to "creative" solutions.


2. Tables of tables.


This is a *good* restriction of the relational model. Hard-nesting is
hard-wiring a particular viewpoint or (access path) into the model,
which goes against the relativistic philosophy of relational. Dr. Codd
set out to purposely avoid hard-wired access paths when he started
thinking about relational due to the navigational messes that others
were creating. However, it does not limit what can be modelled
externaly. One can still model nested stuff using non-nested tables.

It is not a technical "limit", but a philosophical guide-wall.

Yes. It means that your model isn't complete.

"Complete" for what?

Note also relations, as found
in mathematics, do not impose any such limitations. I can have a set of
sets, a set of set of sets, etc and define relations on them.

So? You can also nest a mess inside a mess inside a mess inside a mess.
However, please keep it out of our world.


Relational imposes rules to be called "relational". Otherwise, it would
turn into the navigational messes that motivated the creation of
relational to begin with.

So data in RDBs cannot be properly structured. Fortunately there still
exist hierarchical DBs!

"Properly"? As defined by what?


This is not how complex software can be built. We are in XXI century, you
know.

You are in the navigational 60's.


No, we wish to model them as relations! Polygon isn't a relation. You can
have a table of rows representing polygons, that's OK. Now, write the
SELECT statement that gives me the car position, movement direction and
distance to the next turn I have to do. Show, how this problem can be
decomposed using relational approach.

Use the distance formula to find the nearest matches. The rest is left
as a reader excercise.


And, I don't know where you are getting your size estimates.

From GPS resolution 30cm. Non-relational approach can reduce the amount of
data needed for search, use k-trees, for example. But you have to stick to
X=a Y=b, which is absolutely unrealistic.

Relational does not dictate implementation. Yes, it means you may have
to have custom programmed RDBMS engines to get the most compact
representation possible, but that will be the case no matter what you
use.


I don't know. I do notice that academics tend to be poorly trained in
RDBMS.

Hmm, AFAIK, academics aren't trained, they train others! (:-))

Only in their field.

Further, if there are specialized engines already built to process
things such as Bayesean networks or neural nets, obviously it makes
sense to go with those specific already-built solutions. RDBMS shine
where you have *different uses* for the *same* info. Those things you
list tend to be *same* uses for the same info. See the difference?

Yes. In short RDBMS is not a paradigm. End of story.

What precision math are you using to recon that?



No, will not, because you already have conceded that whatever level it
could be, it is unsuitable outside some niche applications.

*Your* examples are the niche. You are the one standing inside a small
circle, not me. You must have been in school too long or something,
thinking science-lab textbook projects reflect the quantity and style
of real world problems.


I said compiler/interpreter, not the CPU. However, CPU is a similar
example: the machine code is just data to it.

Yep, and I don't care about machine code.

This is about analogies showing relativism, not what you deam
important.


A developer may think of a function as
"behavior", but the interpreter treats it more like data if we look at
other processes that read what we normally call "data".

That the point, software is developed, maintained and finally scraped by
humans.

I don't see how this relates to the relativistic viewpoint of behavior
and data.

You need a paradigm conformant to this relativism [=data abstraction]. ADT
is the vehicle for this. Either with OO or with pure relational (so that
ADTs are limited to cells) is no matter. The latter is just much weaker.
What you propose is outside.

So you claim.


--
Regards,
Dmitry A. Kazakov

-T-

.