Re: Database access sucks!

From: Nick Malik [Microsoft] (nickmalik_at_hotmail.nospam.com)
Date: 01/07/05 

Date: Thu, 6 Jan 2005 23:05:56 -0800

you are right... it isn't necessarily the developer's fault. The tools
changed in a subtle way and that caused some problems.

I apologize for implying otherwise. 

-- 
--- Nick Malik [Microsoft]
    MCSD, CFPS, Certified Scrummaster
    http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
   I do not answer questions on behalf of my employer.  I'm just a
programmer helping programmers.
--
"Doug Stoltz" <NoSpam@myemail.com> wrote in message
news:66991638-F272-413A-8D38-533FE765AFE5@microsoft.com...
> Nick, I have to address one of your statements about "lazy developers"
> misusing server side cursors.  In VB6 DAO recordsets the default was
client
> side cursors, when ADO was introduced the default was server side cursors.
> If you were testing in a small shop on a fast LAN the response time is
barely
> noticable.  I think the problem is that the default in ADO should have
been
> client side cursors.  This probaply lead to the scalability problems more
> than programmer *laziness*.
>
> I'm sure there were many programmers out there that did not notice the
> difference until they rolled out into a different environment.
>
> Cheers
>
>
> "Nick Malik [Microsoft]" wrote:
>
> > "Relaxin" <me@yourhouse.com> wrote in message
> > news:eY797Sb8EHA.2032@tk2msftngp13.phx.gbl...
> > > > Well, then you might need to redesign your app - maybe you don't
need
> > > > to select ALL the records INCLUDING the pictures! Maybe just rewrite
> > > > your app to select FEWER records, and leave the images in the DB,
> > > > until you REALLY need them.
> > > >
> > > > Heck, it's not ALWAYS MS's fault when your system is designed badly!
> > >
> > > Just the answer I would expect from a MS junkie.
> > >
> >
> > While it is unclear if the recepient of that comment would consider it
an
> > insult, it is clear to me that you intended to insult him.  Let's keep a
> > cool head and discuss technology, OK?
> >
> >
> > > If I want to cache all the records to the client then MS should allow
me
> > > that option,
> >
> > why?  If you are referring to server-side cursors, the option created
> > unscalable applications.  It was only intended for very narrow uses, and
was
> > nearly always misused by lazy developers creating apps that were not
stress
> > tested before being inflicted on the general public.  Those apps were so
bad
> > that they gave MS technology a bad name, because they kept failing under
> > stress.  Other database access methods don't allow this goofy design,
and MS
> > probably shouldn't have either.  Sometimes, when you release a
technology,
> > it is hard to see how it will be used or misused.  When you realize the
> > mistake, you take responsibility, correct it, and move on.  The product
> > group did the right thing by turning the spotlight away from this idea.
> >
> > > if I need a live connection, that option should be a available
> >
> > You have it.  DataReader is a live connection.  If by "live connection"
you
> > are referring to rowsets, you have to realize that this was another
wildly
> > misused "feature".  It is rarely beneficial to use them and most apps
that
> > used them did so at their own peril.
> >
> > > Those were the options available to me with OLEDB.
> >
> > And you can still use OLEDB if you want.  No one is stopping you.  It
works
> > just as well under .Net as it did under COM.
> >
> > >
> > > MS shouldn't dictate to me how I should write my application, but
should
> > > give me the option to write it the way that "I" need it written.
> >
> > With power comes responsibility to know how to use it.  While your tools
> > should provide power, they should also relieve the burden of learning.
In
> > other words, they should lead you to make good decisions.  The OLEDB
tools
> > led to some decisions, not all of them were good.  Apparently, you are
> > rather attached to some of your decisions, but that doesn't make them
good
> > ones.
> >
> > >
> > > Also remember, that just because you don't know my design doesn't mean
its
> > > bad,
> >
> > True.  However, you have revealed quite a bit about your design in this
> > series of threads.  From what you have revealed, a few very simple
> > modifications to your design would allow it to work more efficiently and
> > much more scalably.  Is it wrong to point that out?  I'm not defending
the
> > previous poster for his emphasis (which was a bit condescending), but I
do
> > agree that a NG is a place for open discussion, even if it means
discussion
> > of design decisions on your part.
> >
> > > it just means you are a closed minded developer that thinks thier way
> > > is the only way.
> > > That's MS junkie thinking.
> > >
> >
> > Don't be quick to throw stones, friend.  In this discussion, who among
us
> > has shown an unwillingness to admit when a design is using tools in a
sloppy
> > manner to accomplish a goal that shows a strong lack of understanding of
> > efficient or effective data access.  That unwillingness has led to much
of
> > the frustration that is coming out.
> >
> > Perhaps, if you listen carefully, you may hear the sound of people who
want
> > to help you.
> >
> > -- 
> > --- Nick Malik [Microsoft]
> >     MCSD, CFPS, Certified Scrummaster
> >     http://blogs.msdn.com/nickmalik
> >
> > Disclaimer: Opinions expressed in this forum are my own, and not
> > representative of my employer.
> >    I do not answer questions on behalf of my employer.  I'm just a
> > programmer helping programmers.
> > --
> >
> >
> >

Relevant Pages

  • Re: Who is a Good Programmer?
    ... maintainability. ... That is really the only goal for the programmer. ... the *employer* needs to ensure that programs are delivered to the ... the ease of use for the end-user is a problem of design. ...
    (comp.programming)
  • Re: Laws of Intelligence -2
    ... > I was simply saying that raw materials are unintelligent. ... "design" of a wasps' nest. ... >>>animated characters in those films, and your programmer was ...
    (talk.origins)
  • Re: Another $17.4 Billion WASTED
    ... program from shrouded code is anything but "pathetically simple". ... perhaps with user-selected features and compiler ... uncommented code from a programmer that is using ... the detailed software design document put together by the PHD that ...
    (rec.autos.driving)
  • Re: lines of code?
    ... > goose wrote: ... >> is one that could benefit from a multithreaded design. ... against :-) java developers, ... The programmer has to figure it out ...
    (comp.lang.java.programmer)
  • Re: I need more eyes on this one.
    ... by experiencing the problems you mentioned in your code, ... coding without sufficiently thinking about the design or code, ... the worse it gets for the code and the programmer ... project management, processes, ...
    (alt.comp.lang.learn.c-cpp)
Loading