Re: passing parameters to multiple statements - Mailing list pgsql-general

From Pavel Stehule
Subject Re: passing parameters to multiple statements
Date
Msg-id 162867790911180238k6729e93ds1069997ab080cabf@mail.gmail.com
Whole thread Raw
In response to Re: passing parameters to multiple statements  (Ivan Sergio Borgonovo <mail@webthatworks.it>)
Responses Re: passing parameters to multiple statements  (Ivan Sergio Borgonovo <mail@webthatworks.it>)
List pgsql-general
2009/11/18 Ivan Sergio Borgonovo <mail@webthatworks.it>:
> On Tue, 17 Nov 2009 20:16:36 -0800
> David Fetter <david@fetter.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, when
could to save some money. But it is very wrong for customers - and for
programmers too. Only very trivial application should be designed
generally and with same SQL code for all database engines. Why:

a) you cannot use a stored procedures - it should have very
significant impact on effectivity
b) you cannot use a fulltext function - if you use LIKE, then your
application is dead on bigger data.
c) you cannot use a triggers - then all audit and check logic have to
be processed on client part - your application will be monolithic and
heavy. This is very significant, because fixing bugs and enhancing is
more expensive.

When your application isn't trivial, then is very good to use
decomposition, identify database layer API and creating and
maintaining separate modules for different databases. Using common
code for all engines is very expensive - then you don't develop, then
you searching common space - but it is very difficult. It is true, so
db engines shared some functionality now, but they doesn't shared same
bugs. And you have to put all together. Debugging, fixing of this
applications is very very expensive.

Pavel


>
> --
> Ivan Sergio Borgonovo
> http://www.webthatworks.it
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

pgsql-general by date:

Previous
From: Joao Ferreira gmail
Date:
Subject: Re: Data Directory size increasing abnormally
Next
From: Tech 2010
Date:
Subject: vacuumdb: vacuuming of database "xy" failed: PANIC: corrupted item pointer: 19227