[AccessD] LINQ

Hi Guys:

IMHO there is a moving away from database centric applications. Dot Net and
associated ADO.Net with it's Datasets are an attempt by MS to move an
application away from reliance on the server for processing pages and
pointing the BE DB to what it should be doing... managing data. 

Dot Net is an attempt to make applications more distributive. In a properly
written program it should call back to the server when it needs to select,
add, modify or delete (a) record(s) and between then it should run as if it
is a stand-alone application. (There is of course a startup 'load' process
but after that...)

I am currently investigating 'Cache', an alternative database and have been
delightfully entertaining with it very interesting concepts. If you can
imagine a field handled like a Class, with all the properties, methods,
events with overloading, encapsulation, aggregation, custom data types, etc
etc. After a number of classes are constructed they can be inherited by
another super class and so on. All the standards and relationships
surrounding a proper class structure can be implemented. The process is very
intuitive for those understanding the fundamentals of OOP. 

When all is completed the system can generate a SQL schema with all the
constraints, rules, SP, UDF, structures, tables and databases. This is not
to be fooled that this is just a code generator as the schema displayed is
just to give the old SQL designers the warm and fuzzies. It generates a full
XML schema just as easily. The database structure can scale virtually to
infinity and how that would be represented I can not imagine. Under the hood
is an ultimate highly optimized relational hierarchy. Access to any data is
fast regardless of which ghost 'database', 'table' or 'field; it resides in.

The whole structure distributes itself from servers to clients with little
effort on behalf of the database designer. For remote systems there is not
the issues around 'publishing', 'subscribing' and 'synchronizing' as in MS
SQL and Oracle. So far I am very impressed. The next step is to see how it
handles a few million pieces of data and then the last aspect is how it
responds under load.

Do not get me wrong; I am not embracing Cache over MS SQL or Oracle, as I
know them well as do my clients. It is that this technology has proven
itself stellar in implementation and if it performs as well with volume and
under load I will have no legitimate reasons to not recommend it.

Does this Cache database follow Codd's rules... I can not say. The internal
implementation is hidden and I have not the knowledge to go digging.    

Jim 

PS If you are interested in a fully function, single user, free Cache
database check out: http://www.intersystems.com/cache/index.html and
http://www.intersystems.com/cache/downloads/index.html. The download comes
with a full set of step by step tutorials; it runs on any Linux, Mac OSX or
Windows distribution from 98 up. It takes up little room (38xK), requires
little memory (128Mb+), can still function on slow machines (400Mhz) and is
simple-stupid to install. Compare that to Oracle 10i.   



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/



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.