Re: SQL

Dmitry A. Kazakov wrote:
On 12 Feb 2006 13:19:28 -0800, topmind wrote:

Dmitry A. Kazakov wrote:

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.

Which flaws you are talking about? SQL has types, is it a flaw?

Perhaps I used "flaw" too losely. My point is that what SQL needs is
not necessarily what relational needs.


So far you have shown no traces of any concept, which could make relational
independent on types.

And you've showed nothing that makes it dependent on them (barring a
minimal set of operations).

It is a mistake of your own. I saw no indications
that it is anyhow shared by DB community. Look at what respected people
like C.J. Date do. Do they propose to get rid of types in DBs? Nope, they
do exactly the *opposite*.

Like I've said multiple times, the type system is or can be orthogonal
to relational.

They might disagree with some of OO dogmas, I
disagree with many of them too. But, again, nobody of sound mind would
attack extensible types systems. People are only disagree on how a types
system should look like.

Are you talking about relational proponents, or general programming
language proponents?

I will agree that "dynamic relational" has not been something that
seems to have many backers, but it has does not have any declared
detractors that I know (other than you perhaps). We have programming
languages with various type systems to various levels, so I see no
reason not to extrapolate the idea to relational.

As far as I can tell, relational only requires an "expression system"
that can return Boolean-interpretable results on operations on columns.
(This does not mean that all operations have to return Boolean-able
results, only that they exist.) What makes up the expression engine is
not dictated by the philosophy of relational.

Also note that it does not have to return an explicit Boolean "type",
only a convention that the relational engine can recognize as being
"true" or "false". Thus, for context typing we may define "false" as
being any one of "0","false","no", and blank (where spaces and
capitalization are ignored) and everything else as "true".

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

Then answer my question. The result should have a constraint, which
constraint it will have in your "disconnected" view. It is a simple
question. Should your customer know when your program will crash or not?

I think two different subjects got confused here. One is how to
classify your range clause feature, and the other is whether type-free
(context typing) systems are useful. What to call something and whether
it is useful are different issues.


The biggest problem I see with it is that different app languages are
better for different kinds of apps.

Limited applicability of relational approach by no means imply that no more
general approach can exist.

"General" does not necessarily equate to "better". Relational is a
philosophy of organization; and to fit it you must follow certain rules
and guidelines. Obviously the same stuff can be done *outside* such
guidelines. However, the result is often shanty-town roll-your-own
every-man-a-Picasso software or structures. It is a tradeoff of
standards versus non-standards.

I don't claim that *everything* should be forced into the relational
standard, only that those that fit it do better under it because we
don't have to conceptually and perhaps physically reinvent the wheel,
at least not the entire wheel.


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.

Either you know the "situation" or not. When you know it, so you know the
type. Then you cast the value to that type and continue. This is what you
propose: explicit casting all over the program!

There is no "casting" in "context typing". Casting requires a hidden or
side "flag(s)" that tells what type a variable is. Context-typing vars
have no such flag. Every variable is generally tracked as a string (or
array of strings, depending on how arrays are implemented) with no
other indicator/flag/marker of any kind. Just a naked string.


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.

I.e. it will crash, because the internal representation of both is
different, and as you said Foo() cannot determine which one it deals with.
Dynamically typed /= untyped.

No, internally both assignment statements result in *exactly* the same
thing. The interpreter does *not* track whether it was assigned with
quotes or not in context typing. Dynamic typing perhaps does, but not
context typing.

In context typing the "types" are purely in the mind of the programmer
and/or library writers. They don't exist in the language, and thus are
a fuzzy, situational, conceptual concept if they are "there" at all.
The interpreter tracks zilch type info. The interpreter itself has no
concept of "types". There is no objective way to look at the
context-typed language definition nor interpreter and identify anything
about "types" in it.

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.

So? Can you name the parameters to satisfy *any* financial application?

"Any" is a very tough request. I might hit 99%, but I cannot anticipate
everything.


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

But you do claim that it (decimal fixed-point arithmetic) is suitable for
all financial domains and for all domains where a DB comes in
consideration?

First, I don't know if "fixed point" is an appropriate description. It
tends to mirror how people do arithmetic on paper. Second, see above
with regard to "all".


Remember that the ability to have custom operations does not
necessarily violate relational.

Didn't I say that? I said that relational could be consequently applied
only with ADTs available for the cells.

Please clarify.


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.

The problem is not in how "<" is computed. It is in how SELECT and WHERE
interact. And there is no way in relational to influence this. As I said,
it is O(n). To get it better than O(n) one need change the engine to
kd-trees for example. Then it will no more decoupled from the data, because
kd-tree won't let you change WHERE clause. kd-trees aren't decomposable
this way. A relational interface fits to a kd-tree as a beach umbrella does
to penguin. That's the whole point. In relational there is no way to spell
"engine." This level of abstraction is beyond relational decomposition. You
can interface a kd-tree engine relationally, but you cannot implement it
this way.

I would like to investigate example use-cases. Was the snipped-out
"distance" an example of what you talk about? That was the one where I
suggested:

...WHERE cityID IN getClosestCities(&targetCityID&, 200)

I suspect that a domain-specific operation can be devised for the
situations you talk about to take such calculations into the
"expression domain" instead of direct relational queries. Relational
does *not* have to be all or nothing.

Another approach that I did not mention is to let the query optimizer
recognize special cases and automatically optimize the query to use the
special domain-specific engine. However, this requires fancier parsing
on the part of the optimizer. For the distance example, the optimizer
can say, "Hey, we are doing distance-based calculations here. Let's use
the special engine instead of our default looper." Again, relational
"math" specifies what you want, not how to get it. Thus, if the parser
can find an execution shortcut but still satisfy the requirements, then
it does not violate the meaning of the relational equation. By
following a known set of relational rules, such "optimization math" is
easier to do or build.


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.

"Not working" is defined as economically infeasible.

Next time please say, "not feasible" instead of "not working". The
second implies that an answer will never come or that the machine will
crash.

Either way, your alleged big-Oh claim is still being scrutinized.


--
Regards,
Dmitry A. Kazakov

-T-

.

Relevant Pages

  • Re: SQL
    ... to have an ability to place things into cells ... It is a language issue then. ... An RDBMS engine that may ... Put a program code in a relational table and write compiler in SQL ...
    (comp.object)
  • Re: SQL
    ... The "expression engine" can be logically seperated from a relational ... query language, in theory they could without busting relational. ... They all are typed, as well as SQL. ... everything as pretty much a string. ...
    (comp.object)
  • Separation of Relational Engine from Domain Math
    ... A solution is to move such operations to the domain language ... Standard SQL may not allow such, ... of domain math from relational math. ... I have not seen much info about how and whether the "expression engine" ...
    (comp.databases.theory)
  • Re: SQL
    ... >have also drafted a relational language myself, ... >2 or so SQL competitors, and they are in draft mode for the most part. ... For any database language, you need an engine, ... besides a simple parser you NEED an optimizer, ...
    (comp.object)
  • Re: Full-Text Catalog does not build...
    ... You're welcome, Oleg, ... I've not confirmed if the Arabic language will be a FTS supported ... language in SQL Server 2005, you may want to review the ...
    (microsoft.public.sqlserver.fulltext)
Quantcast