On Wed, 18 Nov 2009 11:38:46 +0100 Pavel Stehule <pavel.stehule@xxxxxxxxx> wrote: > 2009/11/18 Ivan Sergio Borgonovo <mail@xxxxxxxxxxxxxxx>: > > On Tue, 17 Nov 2009 20:16:36 -0800 > > David Fetter <david@xxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
