Re: What so special about PostgreSQL and other RDBMS?

Erland Sommarskog <sommar_at_algonet.se> wrote in message news:<Xns94E8F322F2011Yazorman_at_127.0.0.1>...

> Quirk (quirk_at_syntac.net) writes:
> > [comp.databases.ms-sqlserver removed from Groups, not intersted in
> > windows versus unix holy war]
>
> It appears that you failed to do that. That is the newsgroup from
> where I read this thread. If you feel this group is not the venue
> for you, just don't reply at all.

Sorry. This time it's removed, so if Erland is not able to see the response, I guess this discussion is over, since he already claimed that I would agree with him if only I had more experience, he already shot his load anyway.

> And if you want to avoid holy wars, don't come with blanket statments
> about "terrible operating system" or barf just because people say
> "SQL Server".

Erland thinks that the holy war is due to my blanket statements, and that is the problem, the real truth is talking sence to windows zealots is useless, most do not even understand their own systems enough to discuss them, and the ones that do understand read other news groups, so its best to simply avoid the ms specifc newsgroups.

> > Which would be a better product if it were not tied to a particular OS
> > at the very least, and, if possible, not to a particular database
> > either.
>
> Only if you hold non-tiedness as a religious belief. Making a system
> portable over platforms, not the least RDBMSs, is very expensive, and
> I would suggest that our customers prefer to get more functionality
> out of the system.

Yet it is obvious that by using phrases like _would be better_ and _if possible_ I am in no way holding anything as a religion, only giving good design advice. The only zealot is Erland, who is trying to send the message that abstracting data access and not depending on MS SQL would be folly, because he is a MS SQL Shill, Most Valuable Peon, as it says in his sig.   

> > try this:
> >
> > * create a wrapper around the execute binding, that way your
> > application can at least execute stored procured on any backend that
> > supports them.
> >
> > * use standard syntax as much as possible.
> >
> > * issolate the use of non standardized syntax in as few procedures as
> > possible.
> >
> > How difficult is that?
>
> Very.

> And if you had any experience of developing an enterprise OLTP system
> you would know that.

You see, it would be *very* difficult, but only a man with great expertise, like Erland, can know why. Typical FUD.

> >only extream performance concerns are generaly a good enough reason,
>
> Rewriting an UPDATE statement which actually used standard syntax
> (correlated subquery in the SET clause), to one that use the
> proprietary FROM clause with a derived table, slashed execution time
> from two minutes to a few seconds.

Again, one, unqualified example, we do not know why the update statement is so slow, nor do we know if the proprietry from clause is the only, let alone the best solution, nor do we know whether other servers would have the same issue, nor do we know if Erland's data model itself is behind the problem, yet we should automaticly believe Erland that this proprietary from clause is the only way and that abstraction from MS SQL will lead us to ruin.

Also, of course, you may have noted that the final point in my recomendation to Erland is "issolate the use of non standardized syntax in as few procedures as
possible." So even if a propietary clause was needed, it could be used, but if its use is issolated, then porting is much easier, because you know wich procedures contain nonstandard syntax.

I hope none is fooled by his nonsence. Received on Fri May 14 2004 - 03:37:31 CDT