Re: passing parameters to multiple statements

On Wed, 18 Nov 2009 11:38:46 +0100
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:

> 2009/11/18 Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>:
> > On Tue, 17 Nov 2009 20:16:36 -0800
> > David Fetter <david(at)fetter(dot)org> wrote:
> >
> >> On Tue, Nov 17, 2009 at 09:33:05AM -0700, Konstantin Izmailov
> >> wrote:
> >> > Some companies have policy to stay DB agnostic, i.e. use
> >> > standard SQL only.
> >
> >> That's called shooting yourself in the head.
> >
> > I'm a small fish. I use just Free software and still I think that
> > departing from agnosticity has its cost even if you don't have to
> > pay license costs.
> > Especially if you did it without knowing it or with no reason.
> > Many times departing from agnostic code is caused by:
> > - lack of knowledge of standards/more than one DB
> > - early optimization
> >
> > It's just a matter of where you're going to compromise and why,
> > but you've to do it consciously.
> >
> > eg. a lot of code could run on mysql and postgresql as well at no
> > cost, but many people just ignore there is something else other
> > than mysql.
> > That's shooting yourself in the head without even knowing the
> > reason.

> Sorry, but David has true. I understand, so management is happy,

I didn't say he was wrong.

As usual it is a matter of knowledge and trade off.
How can you say what's better if:
- you don't know what is standard
- you don't know the performance impact of writing something in a
dialect of SQL rather than in a standard way

One thing is saying you accept the need of breaking compatibility
for some DB another is saying that pursuing writing standard code is
reckless since it makes all projects too complex and bloated.

Ignorance and dogmatism are strict relatives, but I'd say the former
is the root of the later.

In fact what I generally observe is:
- we just know [this] (ignorance)
- this *looks* like it will run faster/be easier to write if we write
it this way
- we tried it on another DB and it performed really bad/was really
complicated to rewrite
- everything else other than [this] is bad, why should we care
(dogmatism)

Depending on the domain of the application the DB may not be such a
critical part of the overall, and still many things may easily be
written in a way that is independent from the DB.

In my experience you may end up writing 90% of code that could easily
be written in a standard way and with no appreciable difference in
costs (performance/coding).

Writing stuff in a way that it will make cheaper porting code may
even protect you from the changes in the DB you chose as a target.

A policy that mandates the use of portable SQL code for any part of
any application that you're going to write in a company is equally
insane as a policy that mandates to write all code for all
applications in python and make them in such a way that they could
be automatically translated in any language whose name start with
p ;)

But I think such kind of policy is rarer than the programmers that
know more than a couple of SQL dialects.

I don't think companies with such an high level of dogmatism can
survive enough long to get involved in something that is not
trivial, while it is far more frequent to see applications that
don't have such an high coupling with the DB that still are dependent
on it just for lack of knowledge of SQL.

--
Ivan Sergio Borgonovo
http://www.webthatworks.it