sql server programming: There is little evidence that the sql community understands the
concept of a table as a variable let alone its significant
implications. Yet there is ample evidence that the sql community
thinks that it is practicing relational principals within an sql
database. This would seem an awkward state of affairs given that
the concept of table types and variables lies at the heart of a
relational database.
Every table created is at 'inception' a table variable. There is
nothing to be done additionally to a table to change it to a
variable. This is a basic concept in a relational database. And
understanding this should lead to the idea that operating on
a table variable is significantly different than operating on
a table that is...well not a variable :)

I have therefore written a no nonsense and straightforward
article to clearly present the idea of a table as a variable.

http://beyondsql.blogspot.com/2007/09/dataphor-all-tables-are-typed-variables.html

I do hope it helps.

best,
steve

[quoted text, click to view]

Steve,

To my best knowledge you can do all that and much much more in C#
and .Net. You can declare arrays as well as other more intelligent
data structures, initialize them, persist them and so on. I haven't
seen anything I cannot do easily in C#, and C# is not my first
language. Please correct me if I am wrong.

Nice write-up. I have a minor nit to pick though.

[quoted text, click to view]

At inception, you are creating a set of type/attribute name pairs to define
a non-scalar type, in particular a table type. Therefore, it is the type
that you define before declaring the variable.

Not sure how important it is in the SQL world, however a relation header ( a
set of type/attribute name pairs ) that maps to an unique internal predicate
is an essential to the integrity of the relation type. Once you use a CREATE
TABLE statement with a table name then you have a variable. And obviously
you can use compare or similar operations like UNION, INTERSECTION etc. on
different variables of the same type.

--
Anith

[quoted text, click to view]
Thank you sir.

[quoted text, click to view]

I'm not sure I follow you here. You seem to be raising the question of
which comes first the chicken or the egg :) I'd prefer to take the most
basic common sense approach and communicate that the variable and its
type definition are one construct. The variable only exists at the
pleasure of its type. And a type does not exist without a declared
variable.
Now 'maybe' your on the subject of instantiating the variable. If so
here's my attempt at it.

These two statements raise an error. The 1st statement is correct and
defines the var with a heading. The select is the real error because
the table (variable), while a valid typed variable, has no instance
associated with it.

var MyLTable:table {ID:Integer,Y:String} ;
select MyLTable;
Error

The fact that var MyLTable is valid as a type is shown here. If it
wasn't valid then var NewTable could not take its type definition. And
the var declaration of NewTable takes the type of MyLTable *and*
it is instantiated. That there is an instance of NewTable allows
the select.

var MyLTable:table {ID:Integer,Y:String} ;
var NewTable:=table of typeof(MyLTable) {};
select NewTable;
ID Y
-- -

I've choosen not to get into things like instances because I think it
can obsure the central concepts. And I'm not so sure that instances
will go over well to an sql developer:) But I'm more than willing to
listen to alternative views:)

[quoted text, click to view]

This is the big picture I'm trying to show. But I'm realizing that without
an understanding of very basic concepts it doesn't seem to register with
many. It is so different than sql yet has so many ideas that carry over.
It is a both a simple and difficult subject to 'communicate'. We shall see:)

best,
steve

[quoted text, click to view]

Hi,

You are NOT wrong, you are absolutely correct! This is precisely the
reason D4 was constructed from net. The concept of a strong typed
language, the concept of a class is absolutely necessary for something
like D4. The question is after you have your data structures then
what? Inevitably in IT the road leads back to sql, ie. Sql Server.
This is the great irony. How do you use these structures in the context
of a database. Do you want to bastardize these structures so they fit
in the context of sql or do you want a database context to maximize
them. It is a new 'context', a very new context that I write about:)

I have written that MS had it backwards. They shoehorned net into
the context of Sql Server. Had they only thought about putting sql
into the context of net. And if they did should you logically expect
that that sql would still be the sql of S2005? It could be significantly
different. Perhaps something like D4 :)

best,
steve

Steve,

[quoted text, click to view]

I am focusing on the subtle difference between a scalar type and an
unencapsulated type ( specifically a tuple type or a relation type ).

[quoted text, click to view]

Are you sure? I would say a variable cannot exist without a type, however a
type exists independently of any variables. One declares a variable of a
given type only to associate it with an operation defined on that type --
obviously possreps and expressions follow.

[quoted text, click to view]

No, I am referring to the explicit need for a type generator for tuple and
relation types which is different from having a declared type built-in.
Integer does not need a generator, the set of all integers and its
associated operators exist as they are. On the other hand, relation and
tuple are generic types with generic operators like UNION, JOIN etc. TTM
defines it under prescriptions 6 & 7.

Consider two relation variables, A{a, b} and B{x, y, z}. The type of A is
distinct from the type of B though they are both of the generic nonscalar
type relation. You'd need the language support to define explicit types for
A and B so that you can subsequently declare corresponding relation
variables. Your article did not touch on this point which I thought might be
important.

However, I do agree that is SQL you have no type generator concept that you
can apply on tables and hence it may be irrelevant. As you said, the type
definition and variable declaration in the same construct is the only way to
go.

--
Anith

Hi,

It is not easy for me to answer the issues you raise without it
appearing a total cop out. But I will try:)

My view is much, much smarter people than me have been writing about
this subject and advocating it. With very little effect in my view.
Why not try a different approach to the subject matter and by
implication accept the fact that even significant matters will at the
very least be given short shrift, at the very most be ignored (at any
given time). After all I think it can be argued that Bol is a mile
wide and an inch deep. So how do you 'distill', how do you reduce
concepts and ideas to their lowest levels and still convey their
precise meaning in this somewhat challenging material so it will
register with the average Sql Server/Access user?

For better or worse I do not make use of the language of relations,
I not use relvars, tuples or generic types. Though intellectual
significant this language is perceived as the language of a 'theory'
and hence of little 'practical' significance. I do not talk of
or about the TTM prescriptions per se. And as a result of trying
to convey and make simple points I run the risk of making catagorially
incorrect statements, As such as:
'And a type does not exist without a declared variable.'

In the article I had no intention of going into the idea of the generic
types or generators or trying to explain the idea of a type literal.
All your points are of course valid (now that I more clearly understand
what your saying:) The bottom line is that no one could write documentation
alone the lines of bol for this stuff. There is way to much the user
has to infer from basic ideas (for example the use of basic types to
construct more complex types). You must give people the most basic
and simple knowledge to make these inferences of what is valid and
and what isn't. How do you convey this stuff in a 'practical' way to
make people see it as not a bunch of theoretical mumbojumbo. But I am
always open to suggestions:)

Anith is way too atypical for my approach. But how many Aniths do you
think there are? But your nits are always welcome :-)

best,
steve

[quoted text, click to view]

[quoted text, click to view]

Sure, most ideas that are floated around usually invoke some initial
resistance.

[quoted text, click to view]

I guess it is natural, we wouldn't expect references to Newton's Principia
Mathematica or explanations for the momentum conservation principle in a BMW
Owner's manual. A vendor has no more obligation than to keep the customer
satisfied. Anything else is a magnanimous gesture :-)

[quoted text, click to view]

Given the limitations of this forum, your efforts are well appreciated.
However, data management theory has a set of terms that are well defined and
accepted by the community. In general, when one deliberately uses "simpler"
terms, one runs the risk of miscommunicating and misrepresenting the theory
itself. But in this case, as I mentioned before, it is no big deal.

[quoted text, click to view]

Fabian used to refer to the average professional's ignorance towards
fundamentals as an inherent societal problem. But then we all have our
biases and I think it is partly due to apathy. Types, values and variables
are fundamental to computer science, yet we act as it is not important. We
maybe one among largest group of professionals who can write impressive SQL
that "fix" anything, yet cannot distinguish between fundamental levels of
data representation that permeates all aspects of what we do. Very few among
us care about the benefits of a declarative data management language yet
many of us gladly provide our editorialized versions of why a feature should
or should not be added to a particular product. We rarely ask ourselves
whether we are sufficiently qualified to do that or not. We tend to consider
supporting whatever standards and following the trends are professional
virtues. In this environment, vendors have to establish a foothold to surive
and be profitable. And as data professionals we don't seem to care, nor does
the industry that runs behind bright shiny objects. In an apathetic
marketplace, perhaps this is the best we could do.

--
Anith

[quoted text, click to view]

Your very adroit at making your point. I may be considered irrelevant
but I needn't worry about being accused of being too shallow:)

[quoted text, click to view]

Again my compliments for wielding a very sharp scalpel. But not to
worry, my experience here is reading between the lines is not the
forte of the many:) Perhaps Fabian was just too blunt but nonetheless
quite accurate. I do miss him.

[quoted text, click to view]

One wonders what would be the worse we could do:)

Given the fact that you are an sql expert, and deservedly recognized
as such, I recognize that you honor your obligation as you should.
Perhaps I have lost sight of this (and with others) from time to time.
That was my fault. But you have much to contribute above and beyond
a title. Whatever and however your comfortable with, it is
appreciated. And some of us can connect the dots between the lines:)

best,
steve
P.S I do reserve the right to use an 'ax' when I see fit and risk
recognition as an absolute fool :) But I confess my disappointment that
many misconstrue an 'adversarial' approach with a fools errand.
And this coming from some that I assume have the basic intelligence
to separate the message from the messenger. Surely in the marketplace
of ideas this is not the best we can do. But then again....:( :)

best,
steve

[quoted text, click to view]

Nunca llueve a gusto de todos!

--
Anith