Re: passing parameters to multiple statements

2009/11/18 Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>:
> 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
>

Standard is good. And I prefere standard everywhere, where is
possible. But standard has some parts, thats are not respected and not
well implemented. For example - stored procedures and fulltext. I had
to posibility to see some applications developed by programmers
without knowleadge of these. Nothing good. When I ask, why they wrote
it, they replyed so needs support for T-SQL and Oracle.

Any dogmatism is wrong - yes. But minimally me - and probably David
has very bad experience with design ala "all sql code for all
databases". And I have good experience with different strategy - early
decomposition and separation application and database (engine
specific) layer. Nothing less, nothing more.

Regards
Pavel

> 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
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>