Prev: Constipated publisher (SQL 2005)
Next: DataServices World program: SOA data modeling, data services architecture, LINQ, ADO.NET, Entity Framework and more
From: steve on 10 Apr 2008 06:17
How would you like to create sequential lists in a query? Think of the
possibilities that this ability brings. You could actually explain and
illustrate how queries really work. It's like taking an x-ray of your
query! It's working with two types (tables and lists) for the price of
one :-)

SET-ing your query in ORDER
http://beyondsql.blogspot.com/2008/04/dataphor-set-ing-your-query-in-order.html

www.beyondsql.blogspot.com
From: --CELKO-- on 10 Apr 2008 14:52
>> How would you like to create sequential lists in a query? Think of the possibilities that this ability brings. You could actually explain and illustrate how queries really work. <<

Gee, I guess parallelism isn't important when doing queries. That was
why we got away from sequential lists and went to sets.




From: steve on 10 Apr 2008 22:58
On Apr 10, 11:52 am, --CELKO-- <jcelko...(a)earthlink.net> wrote:
> >> How would you like to create sequential lists in a query? Think of the possibilities that this ability brings. You could actually explain and illustrate how queries really work. <<
>
> Gee, I guess parallelism isn't important when doing queries. That was
> why we got away from sequential lists and went to sets.

History is only history if you are aware of it, as opposed to making
it up. That the system-R team was so heavily influenced by the idea of
parallelism eludes me. Perhaps you are confused by the concept of a
pointer vs. a process. And the fact that someone is a couch potato
nibbling away does not qualify one to be a nutritionist in the same
way as someone practicing sql does not qualify one to represent
themselves as an expert in sets. Please don't confuse sql with
relational. You are invoking the argument of "how" as the driving
force not "what". I do believe you have things backwards!
If you really did a quick tour of relational concepts you would find
'types' at the center, such as the table type and the list type. While
relationally all types are created equal sql sells the idea that they
are not. Sql is the judgement that a table is a higher life form than
a list. Sql sells the idea that a list is the misguided attempt to
represent a table as if their characteristics were not clearly
different as well as their uses. Complete nonsense. A type of pseudo
intellectual
misogyny where women are replaced by lists:)
In what I have presented exactly "how" the list is formed is
completely irrelevant. What possible difference does it make if the
query is executed with parallelism? However it's processed the list
will be populated and will reflect a "sequential" nature. And may I
remind you that is what lists do. And the query will produce a list
whether 'you' like it or not!:) One can use detailed query plans and a
good dose of common sense to interpret them. To that absurd idea that
everything happens
at once think of this as the fork that lets the air out of that:)
You are aghast with the idea of the "cowboy coder" but apparently you
have a lot of sql hillbilly in you:)

best,
steve
www.beyondsql.blogspot.com
From: --CELKO-- on 11 Apr 2008 10:58
>> History is only history if you are aware of it, as opposed to making it up. That the system-R team was so heavily influenced by the idea of parallelism eludes me. Perhaps you are confused by the concept of a pointer vs. a process. <<

This has nothing to do with SQL per se. Parallelism in a set-oriented
model goes back to Cantor and the idea of treating an infinite
collection as a whole rather than a process. All we had was the old
Sigma and Pi notations and the concept of the limit of a process. The
lack of a set concept in math is what made Hilbert's hotel a problem
in its day. Hilbert wanted to knock on every door to move the guests
around; Cantor just shouts down the hallway and tells everyone to do
it all at once :)

>> If you really did a quick tour of relational concepts you would find 'types' at the center, such as the table type and the list type. <<

I would call a set, list, array, etc. data structures rather than a
types. I might put Domains, which are built on "types with
constraints" at the center ..

>> SQL sells the idea that a list is the misguided attempt to represent a table as if their characteristics were not clearly different as well as their uses. Complete nonsense. <<

I agree; a list depends on operations (head(x), tail(x), cons(x,y),
etc.) that have no counterparts in a set model. Likewise, the UNION
of a list makes no sense. But I don't see SQL as getting confused on
this point; I see newbies who are writing 1950's magnetic tape file
systems in SQL. They just don't get it.

>> A type of pseudo intellectual misogyny where women are replaced by lists:) <<

That is a weird analogy, even for you.

>> What possible difference does it make if the query is executed with parallelism? <<

(1) Speed of execution would be the big one for most people.
(2) Access to data is a major difference. Consider the statement
"SELECT a, (a+b) AS c, (c+d) AS e FROM Foobar;" which will work just
fine in a left-to-right processing order. But if columns a, c and e
are retrieved and constructed all at once, then c is not available for
e to use. Hell, you can write "SELECT (a+b) AS c, (c+d) AS b FROM
Foobar;" and get a result in a left-to-right language!
(3) This parallelism is why IDENTITY and other auto-increment
"features" make no sense when you insert a set. Given a statement
like INSERT INTO Foobar SELECT a, b, c FROM floob;" which puts (n)
rows into Foobar, how do you determine their auto-numbering? What do
you do when many sessions execute the same statement at once?

>> To that absurd idea that everything happens at once think of this as the fork that lets the air out of that:) You are aghast with the idea of the "cowboy coder" but apparently you have a lot of SQL hillbilly in you:) <<

That is changing fast. Have you ever worked with Teradata, WX2, SAND
or Vertica? The parallelism is at the hardware level. A little while
ago, someone put Postgres on a box with a solid state disk (I am
tracking down the article); it is all parallel processing and
associative memory access.
From: Anith Sen on 11 Apr 2008 11:18
>> I would call a set, list, array, etc. data structures rather than a
>> types.

That would be a much lower level of abstraction. The term data structure has
connotations to storage, manipulation algorithms and efficiency all at a
much lower implementation level while types are at a higher logical level.

>> I might put Domains, which are built on "types with constraints" at the
>> center ..

Not sure if such a distinction is any useful since a type, by its very
definition, includes constraints and operations.

--
Anith


 |  Next  |  Last
Pages: 1 2
Prev: Constipated publisher (SQL 2005)
Next: DataServices World program: SOA data modeling, data services architecture, LINQ, ADO.NET, Entity Framework and more