Re: SQL

Dmitry A. Kazakov wrote:
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.

To a point. One can use them barely or heavily.

Even SQL cannot avoid them.

SQL is more or less based on "COBOL thinking". It is not the best
possible nor most type-free that a relational query language can be.
Bashing SQL as a language is like pointing out flaws in Java and
painting all of OOP by those flaws.


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. ]

You are *calling* constraint parameters "subtypes". One can also view
them as simply constraints without any connection to types. In other
words, you are looking at the world through type-colored glasses. I
don't dispute that such "can be viewed as types". Perhaps every
language *can* be viewed as types. However, as stated many messages
ago, that does not mean that everything *is* types or should use the
concept more. In short, you are getting carried away with a viewpoint.

It would be just like some FP or Smalltalk fanatic saying, "I can view
everthing as closures. Therefore we should use the concept more and
view everything as closures." I hope you see the flaw in that
reasoning.



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.


There is a lot of code written in PL/SQL and Transact-SQL, which is SQL
with procedural additions. I don't necessarily agree with this
approach, but I am pointing out that route exists in decent quantities
now.

The biggest problem I see with it is that different app languages are
better for different kinds of apps. One of the benefits of databases is
that they allow multiple languages and tools to use the same "attribute
model" (database). It facilitates sharing across tools.

I have also used languages which allowed things resembling:

PERFORM myFunction(x, y) WHERE y < 3

It was pretty nifty. Those kinds of things are fairly common in
"collection oriented languages".

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.

I am only saying that your "unknown" statement is false. And I am not
talking about operator overloading. What a given
function/procedure/operation does with a given variable is purely up to
it. It carries no hidden flags or markers that limit or suggest how to
handle it or what operations can be used on it. This is the difference
between "type free" and "dynamic typing".


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?


I don't understand your question. I carries nothing that cannot be
seen.

These are the same as far as such a language would be concerned:

x = "123";
foo(x);

AND:

x = 123;
foo(x);

"Foo" would have no way to tell the difference in a type-free lang.
There is no hidden or side marker that indicates how it was declared.


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.

I did not mean to suggest that this was meant for all kinds of domains.
A scientific library would probably look different than a financial
one, with different truncation/rounding parameters, etc. I should also
point out that "string-based" numbers is probably not appropriate for
scientific apps either. But again the "expression system" is orthogonal
to relational.



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

Again, I did not propose that decimal math is appropriate for all
domains.


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. ]

I would have to study a good set of use-cases from the domain to see
what kind of operations need the most optimization. Not sure I want to
bother with that right now anyhow.

Remember that the ability to have custom operations does not
necessarily violate relational. Thus, one can make:

SELECT * FROM mytable WHERE foo(x, y, z) < bar(m,n)

As long as the expression "foo(x, y, z) < bar(m,n)" returns something
that can be interpreted as Boolean, relational is generally happy with
it. Dr. Codd did not hard-wire the math domain into relational anywhere
that I saw. (And if he did, we can remove it without hurting the spirit
of relational.)



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!


I guess I am not understanding what you are proposing as an
alternative. How about a use-case which exposes this alleged flaw.
DistinctBetween does not iterate, so I don't see where you are getting
O(n) for that particular operation.

Perhaps you want something that can return the closest n
roads/cities/points without having to visit them all. We could perhaps
have a function called getClosestNodes(targetLocat, distance). It would
return the ID's of nodes matching using your favorite fast
implemenation. We could use it something like this:

SELECT cityName
FROM cities
WHERE cityID IN getClosestCities(&targetCityID&, 200)

"targetCityID" is the inserted variable (from app).

For that particular case we had to go outside of relational to get
needed speed, but we don't have to abandon relational *entirely* in
order to do it. (Whether it can be done inside relational, I don't
know. I haven't found a way, but this is not my domain so I am rusty
there.)

Thus, it is not an all-or-nothing issue even if by chance relational
cannot do the entire thing. Reinventing 1/3 of the wheel is usually
better than reinventing all of it.


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.

You have not shown this. At best you have shown cases where it is slow
(still under dispute). Being slow and "not working" are different
issues. And even the slow areas can probably be remedied without full
abandonment of relational.


--
Regards,
Dmitry A. Kazakov

-T-

.

Relevant Pages

  • Re: SQL
    ... Even SQL cannot avoid them. ... 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 ... There is no numeric type for all purposes. ...
    (comp.object)
  • Re: SQL
    ... custom biz app setting. ... Put a program code in a relational table and write compiler in SQL ... SQL is one of an infinite possible relational languages. ... how would making each pixel an ADT or Object improve the picture ...
    (comp.object)
  • Re: Is there a mainframe skills shortage?
    ... That's because the author of the article is comparing it to standard SQL. ... and material around Lamdas and functional programming. ... obvious which languages were the ones to learn. ... stick to writing system software and leave applications to the COBOL ...
    (comp.lang.cobol)
  • Re: SQL
    ... SQL is a specific language with certain ... relational nor query languages. ... which don't fully implement ADT. ... interfaces to such are often not as flexible as query-based interfaces. ...
    (comp.object)
  • Re: SQL
    ... The point is that the relational model is a particular case of more general typed model. ... In SQL you are using types like integers, ... There are bad languages, which don't fully implement ADT. ...
    (comp.object)
Quantcast