Re: SQL

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?

So far you have shown no traces of any concept, which could make relational
independent on types. 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*. 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.

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.

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?

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.

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!

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.

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.

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

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?

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.

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.

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.

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

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: A new proof of the superiority of set oriented approaches: numerical/time serie linear interpola
    ... A constraint is a boolean-valued expression, ... 'Integer variables are nothing more a language device, ... All assignment does is allow one to replace one integer with another. ... you've made that paragraph resemble some programs I've read. ...
    (comp.databases.theory)
  • 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)