[AccessD] LINQ

Arthur,

SQL and the database engine is about providing data to an application, it is
NOT about BEING the application.  As soon as you discuss building an
application then all kinds of considerations take over, things having
nothing to do with the data.  Screen resolution, input devices, local
storage of various things, platform architecture kind of stuff.  All of
these things are done in languages VERY platform specific.  Perhaps not the
best way but there are good reasons for doing so, from application speed to
development speed.  Applications are bigger than the data.  

I have a call center application where data is automatically validated at
the control level as it is entered.  As 5 check boxes are checked and
unchecked, business rules take over and cause other check boxes to be
checked and unchecked.  This data has never even been sent to storage yet,
it is just out in the form so far.  Where data causes program execution
branches, displaying or not displaying entire tabs on forms, or allowing /
preventing specific forms from being seen.  Where user rights dictate
whether specific controls can be used, whether specific fields can be seen
and used for data entry.  

Where data is exported to word documents and excel spreadsheets, stored out
in directories for archive purposes, attached to emails and sent, where
documents received as attachments are stripped off of the emails, placed in
directories, and then data is extracted from the documents and appended into
the database.  Data is pulled out and faxed automatically, inserted into
emails and emailed automatically etc.  The data is about claims, but the
APPLICATION is about customer service, handling a claim in the most
expeditious manner in order to ensure that payment is prompt.  The data
collected is by and large just a byproduct of the processes occurring to
validate a claim.

I absolutely believe that "what the database engine can do, it should do".
However what the database engine can do is a TINY part of what the
application does.  In order to develop powerful data-driven APPLICATIONS I
need powerful data manipulation tools integrated right into my language.
THAT is what .NET is trying to attempt.  My APPLICATION will NEVER just port
to a different ENVIRONMENT.  To make the data store transparent is
definitely a good thing, I agree whole heartedly.  But don't cut me off at
the knees getting at the data.  If I have to use a specific data store (as
long as it is a powerful one) I simply couldn't care less.  It would
definitely be better if the interface between the language and the data
store could swap out data stores, that would be a nice thing, but certainly
not critical.  AFAICT .Net can indeed "talk to" other data stores than
Access and SQL Server.  

You wax poetic about the BE / data store / database engine / SQL Language
but it is just a critical but tiny part of the bigger picture.

John W. Colby
www.ColbyConsulting.com 

Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Saturday, October 08, 2005 7:01 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [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.