|
|
Posted by William Vaughn on 09/03/07 22:04
I (personally) have to take the blame for some of this churn. As I said any
number of times in my books (especially the early ones), the JET/DAO
interface was designed as a native interface to JET and made a terrible
interface to SQL Server. ODBC the first one-size-fits-all (OSFA) generic
interface was supposed to bring utopia to the data access world. It ignored
the fact that just because you put in a door that anyone with a key could
open, once you got inside the room nothing was the same. So what if you
could open a connection to SQL Server or Oracle (or even JET) using the same
interface method. Most aspects of doing so were different. Once connected,
one was an ISAM engine, the next was best accessed with stored procedures
and the next while it could use stored procedures, they weren't coded the
same or didn't behave the same. We were right back where we started but
running the train from the caboose via teletype twelve cars back from the
engine.
RDO was my (and about three others in the VB team) attempt to get a better,
cheaper, lighter interface to Microsoft SQL Server. It worked (to a great
extent). As an intended side-effect it got the JET team to fix the first
versions of ADO to work correctly with stored procedures. 9 or 10 versions
later they're still trying to get it right. Each time they change it, the
apps that depend on the MDAC stack creak, bend or snap. Thank the stars
they've now decoupled the stack for SQL Server (SNAC)--everyone else is
still pooched.
According to the data access gurus, the downside to ODBC was perceived by
(... don't get me started on the other Mr. V) to be only suitable for
"relational" databases and MS needed more. They wanted the data access layer
to ALSO access flat data, round data, object data and corkscrewed up
data--thus OLE DB was hatched. It added layer upon layer and when all things
were done it was no faster and actually slower than ODBC and DAO--but you
could access virtually any kind of data. All you needed was a rocket
scientist to create the OLE DB provider and a language other than VB to do
it with. In their infinite wisdom they created a DAL that could not be
accessed with the most popular language on the planet (outside Redmond).
ADO.NET on the other hand was more of a start-from-scratch approach to let
the objects get closer to the native interfaces like DB-Lib and PL/SQL. It
was supposed to be very light (too light in my humble opinion) and fast and
not an OSFA. Each provider implemented similar base functionality in the
..NET provider but left you in the same place if you tried to create a single
application to access more than one backend.
At this point in time, I'm a bit miffed that we had to abandon some pretty
serious (and powerful, but difficult-to-get-right) architectures in ADO
classic like server-side cursors, fully async ops (including async Open and
fetch) and others. Instead the team has been focused on more and more
client-side library work like LINQ and TableAdapter code generators.
Now we hear that LINQ is (dramatically?) slower than not... I'm not a bit
surprised--is anyone? Of course the processors now-a-days are faster so the
real difference is smaller--as long as you're running a Quad Core Duo at
3.GHz with a RAID 5 array.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant, Dad, Grandpa
Microsoft MVP
INETA Speaker
www.betav.com
www.betav.com/blog/billva
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)
-----------------------------------------------------------------------------------------------------------------------
"Ralph" <nt_consulting64@yahoo.com> wrote in message
news:OR6qUIm7HHA.1164@TK2MSFTNGP02.phx.gbl...
>
> "William Vaughn" <billvaNoSPAM@betav.com> wrote in message
> news:eVAfqhk7HHA.1900@TK2MSFTNGP02.phx.gbl...
>> As cynical as this sounds, I'm with Stephen here. ADO.NET has (IMHO)
>> regressed in functionality in some respects from ADO classic. I would
>> embrace opening up the interface to see what it's doing so would could
>> get
>> around some of the "won't fix" or "can't fix" issues.
>>
> <snipped>
>> >
>> > Does anyone really believe with ODBC, DAO, RDO, ADO, ADO.NET - each
>> > generation has been an improvement?
>> > They are all interfaces on the same set of database technology - which
>> > does not change.
>> >
>> > Stephen Howe
>> >
>
> Yes I believe you can see a clear trail of the improvements.
>
> I am somewhat timid in submitting a post in mild* favor of DAO, ADO, and
> Microsoft's data access technologies in general. After all, Messrs. Howe
> and
> Vaughn, have likely forgotten more about data access that I ever knew. <g>
>
> But I believe it is frequently overlooked that any data access library is
> merely one layer in a stack of technologies. For example...
> [ADO | DAO] <-> [OLE DB | ODBC] <-> ClientAPI <-> DatabaseEngine.
> If one actually attempts to trace what goes on with even the simplest of
> queries - it quickly becomes amazing that it works at all.
>
> "They are all interfaces on the same set of database technology - which
> does
> not change." No, they are not. Database engines change, OLE
> implementations
> change. Microsoft has not only presented us with the programming data
> access, they have also made amazing changes and improvements all down the
> line and back again.
>
> Also Microsoft (who was talking to IBM in those days <g>) was the primary
> sponsor and the major reason ODBC was adopted. ODBC took us out of the
> dark
> ages of when every datasource, vendor, and language platform, had its own
> access "libraries". I don't think MS gets nearly the credit it deserves.
> Doesn't anyone remember the nightmare it used to be?
>
> But sure ODBC had a flaw. It depended on everything to look like tables
> with
> a hierarchal structure. This made working with non-table datasource
> difficult. So ADO came about. ADO's stated goal was Universal Access. And
> it
> accomplished that. We think nothing of using ADO to connect to anything.
> "Give me a provider and I can move the world." <g>
>
> But it is not my intention to provide a history lesson. Wikipedia can do
> that.
>
> Now to the question of why there are mysteries?
>
> With ADO and SQLServer this seems strange - as Steve pointed out - "You
> would think they would have it down pat by now". Especially when you
> consider ADO and OLE DB and SQLServer were until recently the
> responsibility
> of the same team. But why, is basically because of three problems.
> 1) ADO is so prevalent that any fundlemental changes would require massive
> regression testing.
> 2) the specter of the 1998 "United States vs.. Microsoft" civil suit.
> While
> it didn't happen MS came close to being broken up. As it is, they have to
> be
> very careful to share its application programming interfaces with
> third-party companies, and not make any 'improvements' that effectively
> break anything else, or perhaps even more important provide an obvious
> advantage for themselves.
> And 3) the shear complexity of the problem in the sense - what is optimal?
> We all know there are more than one way in programming and no single
> choice
> is always the best choice.
>
> Since the dawn of programming several things have always been paramount,
> picking the best solution, you never knew until you tested it, and the
> next
> situation was likely different.
>
> Yes ADO.Net has flaws, so did ADO, and so did DAO, and so did... But all
> of
> them had their strengths as well. Contrary to popular belief - NONE was
> ever
> a 100% optimal replacement of the other.
> Which is why I always laugh when someone comes out says things like - "ADO
> is the only way to go." Even today DAO with the right engine and server
> will
> thrash ADO. (eg, Jet and DB2)
>
> Anyway this is too long. My apologizes to everyone.
> [*"mild", I wouldn't want anyone to think I'm a MS bigot. I'm still pretty
> m
> iffed over what they did to VB, and the clumsy half-a** PITA that is
> Vista.
> Plus IMHO, if they would listen to me and done things the way I would have
> done it, they would be better off. After all everything goes smoother when
> people just do things MY way. <g>]
>
> -ralph
>
>
>
Navigation:
[Reply to this message]
|