[AccessD] LINQ

Call me an old-timer if you wish, but I do think this is NOT hot, but rather
an extension that attempts to trap developers in MS-SQL. The late Dr. Codd
fought long and mightily to eradicate the distinctions lying between the
implementations from various vendors. MS is not the only rapist in the park,
as it were. Oracle was first. I do NOT like this direction. First and
foremost, it moves application logic into the app or middle tier rather than
the database itself. I HATE this direction! IMO all logic that CAN reside in
the db SHOULD reside there, and nowhere else. 
To the extent that LINQ encourages logic in the front end, I think that it
is a serious design mistake.
I distinguish this objection from an object to extending T-SQL (PL-SQL,
etc.) with new languages and constructs. But I want them all to work with
all SQL implementations. Otherwise the genius of Dr. Codd will be buried
along with him. How sad.
SQL should IMO work just like the web: adhere to the spec, and flag your
differences in BOLD type so that the user-developers will realize that to
the extent they use your extensions, they violate the protocol.
Personally, I have bought into various Oracle and MS extensions and paid the
price for it every time. All this marketing strategy reminds me of a crack
dealer saying The first hit is free. I hate this direction. I want
vendor-language transparency -- everything I write in MS is guaranteed
portable to Oracle, Postgres, MySQL, ANTs, etc. ... In all directions. I
realize that the self-serving vendors have chosen to capture their
customers, but I hate it. In my ideal world, I specialize in SQL not in
MS-SQL or Oracle or any other flavour you wish. I want every line of code to
work in every implementation, and to the extent that the implementation
fails, then I do not want to use that product. I want the vendors to propose
language extensions and upon agreement by the other vendors, every vendor
can then implement the extensions.
The late Dr. Codd is most often thought of as having invented relational
databases. Historically, he had no part in the creation of the SQL query
language. In fact, he had lots of objections to it (c.f. The Relational
Model for Database Management, Version Two, ISBN 0-201-14192-2; Chapter 23,
Serious Flaws in SQL)
I have examined the objections of Dr. Codd in detail and I am convinced that
he is correct. His disciple Michael Stonebreaker produced a superior query
language, but as in the case of betamax v. vhs, it does not really matter
whether you are correct. 
It may be that the application logic moves to the front end thanks to LINQ.
I hope that this does not happen. I am fine with various languages moving
into the back end and replacing or augmenting T-SQL, but only if they are
portable to other SQL implementations. 
I have been down this road before, and I now name it VENDOR-ENTRAPMENT. I
hate it. I have instead a vision much like the SQL spec in which all vendors
agree to comply with said spec, and any cool extensions they wish to
introduce should be subject to the scrutiny of all other vendors. 
Given the db players in the market, any my particular fragment of said
market, MS-SQL is the best answer. But I do NOT want to trap myself or my
clients into this solution! Everything could change next month or year. I
want a migration from product X to product Y to be painless. To the extent
that the db vendors stifle me in this, I understand their commercial motives
but I hate them nonetheless.
Codd was about universality and transparency. Please, let us try to remember
that. So what does this mean in real terms...
Vendor X cannot introduce extension Y without first proposing it to the
committee, and having it accepted. (Example: the pivot extensions in SQL
2005.) Unless and until all the other major vendors accept this new
extension and its syntax, it shall not be considered part of the SQL spec.
Back to LINQ... to the extent that the application logic moves to the front
end, regardless of the language, I get very nervous. This is NOT the
direction in which I wish to travel. My vision is opposite: all front-end
developers use the same set of back-end sprocs and views and UDFs,
regardless of their chosen UI. In this scenario, I make one code correction
in a sproc and all possible front-ends inherit it automatically.
Why on earth would we choose to do it any other way... I do not get it. This
seems soooo obvious to me. Perhaps I am missing something. I imagine 5
front-ends to my database -- Access, .NET, Excel, ASP and Delphi -- and I do
NOT want each programmer of each of these to re-think and re-write the
logic! Instead I want them to comprehend the sprocs, pass the params
required and test the result, then act accordingly. 
EVERYTHING THE BE CAN DO THE BE SHOULD DO. The front-ends should interrogate
and that is all they should do.
A.


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: October 7, 2005 9:39 AM
To: accessd at databaseadvisors.com
Subject: [AccessD] LINQ

Hi all

This is hot:

http://msdn.microsoft.com/netframework/future/linq/

Note the link to sample code.

/gustav