Re: SQL

On 11 Feb 2006 12:54:38 -0800, topmind wrote:

Dmitry A. Kazakov wrote:
On 10 Feb 2006 23:10:35 -0800, topmind wrote:

Well, I think it is a definition game being played here. Anyhow, being
useful for A does not necessarily extrapolate to B. I agree that
systems software may be a place where "types" are fairly useful.

No, they are useful for software in general. Even SQL cannot avoid them.

This is wrong, I gave an implementation with a pre-defined integer type
which also does not define any new type. This didn't satisfy you and you
switched to:

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

I showed that modern languages have no problem with defining new integer
types. [SQL is unable to do this.]

I don't think I would call that feature a "type". A "constraint"
perhaps.

If you add X with one constraint to Y with other constraint and what would
be the constraint of the result?

I am not sure what you are asking. Please attempt to reword it.

That was your idea to separate types and constraints, or? So was my
question.

[ Constraints are applied to types. Constrained types are subtypes. In
general it is called specialization. ]

So, what is your point? That cell types can be any? This is wrong, they
have to be at least copyable and comparable. That relational is defined on
this class of types? This was my starting point.

Sorry, but I don't see the practical significence of that from an
application perspective.

So we can agree that from theoretical point of view relational is not a
paradigm, but a case.

No.

Please don't elude, practical issues were addressed in the following
paragraph.

A for practice, this has a direct implication. With
proper ADTs I can have a relational container library and forget about that
nasty SQL and clumsy, slow, buggy RDBMSs.

So something tested by an internal QA team and hundreds of thousands of
users is going to be more buggy than something you roll your own in a
few months?

Carefully re-read the paragraph above. It says nothing about who will
develop that library. The word "library" implies reuse, right?

RDBMS exist only because in 70s there were no languages capable to provide
a relational library. A desire to have it integrated into *normal*
languages would become obvious, if we consider embedded SQL. Since then
nobody of sound mind could even imagine SQL in place of a universal-purpose
language.

Further, most commercial RDBMS have a "money" or "decimal" type such
that one does not have to use floating.

Come on, already elementary statistical analysis cannot be performed in
fixed-point, because of massive precision loss in division. It is a to
death beaten issue. There is no numeric type for all purposes.

I did not claim there was.

No, you keep on trying to say that numeric types aren't necessary. This
could only be true, if there were a universal numeric type (which you call
"no type".) It is a clear contradiction with:

Same with the type-free approach. If you want a big number, no problem:

x = 2342423423412342343423423.23342039480934509243

Same as

x = "2342423423412342343423423.23342039480934509243"

Now, whether a given function(s) can handle such a number is another
matter. A string-based decimal library can.

See above. You still don't understand that number is not a chain of digits
or a set of bits. Number is a type having various properties. I don't need
numbers if it is unknown how to handle them.

Not "unknown" but rather "situational".

Situation determines the semantics of "+" is exactly same as: situation
determines the type. This changes nothing.

You are thinking in "is-a"
mode. These kinds of numbers don't carry around a "type flag" that says
only a given set of operations can be used on it.

So, the flag carries "situation", and, what is changed?

Please: compute "1"/"3" in
your library!

Ideally the library would have a decimal limitation parameter and I
believe dedicated decimal packages do. It may resemble:

x = divide(a, b, 20)

Excellent, why not

x = divide(a, b, 21)

Note that the value 20 vs. 21, 22, 23... and the very semantics of "divide"
[truncation to n decimal digits] constitute a numeric type. This model is
called fixed-point arithmetic. And there are zillions of applications where
fixed-point is unacceptable. Unacceptable reads: with *any* realistic value
of n.

Again: for any library you have, I can find a counter example where it will
not work. It is a hard mathematical *fact*.

I am not sure what your point is.

We better close this topic. Recommended reading:

http://en.wikipedia.org/wiki/Category:Computer_arithmetic
http://en.wikipedia.org/wiki/Rational_numbers
http://en.wikipedia.org/wiki/Fixed-point
http://en.wikipedia.org/wiki/Bignum
http://en.wikipedia.org/wiki/Floating_point
http://en.wikipedia.org/wiki/Interval_arithmetic
http://www.cs.utep.edu/interval-comp/main.html

This changes nothing. The result is *sorted*. To sort using some *external*
key you have to visit *all* rows. This is at least O(n). It seems that you
don't well understand the background. Read, for example:

http://en.wikipedia.org/wiki/Space_partitioning

I see nothing that keeps an RDBMs engine from using such techniques to
speed up spacial queries.

O(n)

This is only for your "external key" assumption. A custom engine does
not have to use that. A relational interface does not dictate
implementation.

I don't care about interface, give me a relational *implementation*! [ As
for interfaces, I already proposed to reissue all maps in the form of
tables. You weren't much impressed. ]

If dead Girbals can be used to make it run certain
kinds of operations faster, then go for it.

A relational-intended "expression engine" could have a
DistanceBetween(locatID1, locatID2) operation that uses whatever the
best implementation is for such.

LOL! Dear topmind, it is O(n) with *any* implementation of DistanceBetween!

you cannot decompose custom problems into relational.

Yes you can. It is a similar issue as the Turing Tarpit. Some things do
it well, some do it poorly.

Right. For the problems I have presented, relational doesn't work. This is
all I wished to say.

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

Relevant Pages

  • Re: SQL
    ... SQL is more or less based on "COBOL thinking". ... If you add X with one constraint to Y with other constraint and what would ... RDBMS exist only because in 70s there were no languages capable to provide ... The biggest problem I see with it is that different app languages are ...
    (comp.object)
  • Re: SQL
    ... SQL is more or less based on "COBOL thinking". ... possible nor most type-free that a relational query language can be. ... If you add X with one constraint to Y with other constraint and what would ... A relational interface fits to a kd-tree as a beach umbrella does ...
    (comp.object)
  • Re: Parameter??
    ... in common with most available SQL ... given month' Validation Rule or constraint? ... date_col DATETIME NOT NULL, ... The above relies on the Jet implementation to coerce a DATETIME to ...
    (microsoft.public.access.queries)
  • Re: dropping a relationship (i.e. constraint?)
    ... so they may have been something in that SQL statement that JET was not ... ignorant of constraint names until last week. ... CONSTRAINT PrimaryKey PRIMARY KEY (RName) ...
    (microsoft.public.access.queries)
  • Re: How do you mulitply in a field?
    ... asked how one places a unique constraint on a combination of fields ... This will work for Jet in ANSI-92 Query Mode Jet SQL. ... I apply security so that the database can't be hacked. ... If I am selecting only one name, ...
    (microsoft.public.access.tablesdbdesign)