Re: SQL

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

Dmitry A. Kazakov wrote:

Yes, we are talking about features of languages. This is a feature, SQL
does not have.

What is your point? SQL lacks a lot of stuff. Some app langs have range
declarations, some don't. Same with relational languages.

The point is that they are typed, because types are useful.


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.



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.


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. Interchangle implementation does not change anything. For example,
an FP language can be written in an OOP language/style and visa versa.
That does not mean that one is a "subset" of the other. It is just
Turing Equivalency at work.

I suppose you will reply that relational is not Turing Complete. It
does not need to be. Your equivalency criteria has been shown to be
faulty in out outside of relational or SQL.


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? I highly doubt it.


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

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)

Here the last parameter would be the max number of decimals (twenty).
However, the "built in" division operator usually has pre-set limit. If
you don't like the pre-set limit, then use a library like above. (The
downsides of infix operators is that extra or optional (named)
parameters are not easy to add.)


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. Are you saying you can find a way to
break stuff? That just puts you on par with a Russian hacker.


Show me relational being limiting to my domain.

It is enough, that it limits *my* domain!

I think you just remember the parts of your apps where it does not
work. I bet behind most mega number crunching or special-purpose
processing engines is a database or the need for a database to track
input and output sources, input/output items, and/or processing sets,
runs, or schedules of runs. For example, who ran it, why it was run,
who paid for it, how long it ran, what were the inputs and outputs,
where are the inputs and outputs kept, etc.

Of course no. We provide DB support only upon customer request, and only
off-line. There is no DB capable to handle periodic data at 10-100ms rate.
Then because data sources are asynchronous, relational representation of
multi-channel data is rubbish. Furthermore, a medium-sized system has about
10,000 channels. Processing these data in a RDBMS would take days, while
one hour of downtime costs dozens of kilobucks. So DB if used, then only
for overall results and reports.

If RDBMS don't work for your niche for whatever reason, then so be it.


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


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.

Stop here. "Custom" in "custom programmed RDBMS engine" means
non-relationally programmed. Am I right?

Heck no! A custom made/tuned relational engine is certainly as possible
as making a non-relational one. A non-trivial commercial graphics
engine will almost certain be custom-built for graphics regardless of
paradigm used.

No, I meant the paradigm used to *implement* that custom engine. To make it
simpler: will it be programmed in SQL? Carefully consider your answer.

Probably not. Relational has not yet proven very effective at being a
key part of lower-level systems software.

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.


q.e.d.

b.s.


--
Regards,
Dmitry A. Kazakov

-T-

.

Relevant Pages

  • Re: SQL
    ... SQL lacks a lot of stuff. ... Same with relational languages. ... I see nothing that keeps an RDBMs engine from using such techniques to ... A custom made/tuned relational engine is certainly as possible ...
    (comp.object)
  • 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: Is it just me, or is Sqlite3 goofy?
    ... be saying it has gasoline engine. ... SQL database, with an SQL engine. ... No one appreciates the tone in which you report these alleged faults, ... standard as well. ...
    (comp.lang.python)
  • RE: SSIS Perf question
    ... Per your question, when exectuing packages, sql queries/SPs are still ... SSIS engine is to process the workflow of the ...
    (microsoft.public.sqlserver.dts)
  • Re: Setup of SQLExpess Options
    ... application, you've included the SQL Express as pre-requisites, currently ... **Write a C program that uses COM to interoperate with DMO9, WMI, or SMO ... your custom .net code in setup project ... Microsoft MSDN Online Support Lead ...
    (microsoft.public.vsnet.setup)