Kjell Rilbe wrote:

> Hi Sven Erling,
>
> The biggest diff between you and me is probably that you've used
> Firebird so much that you do things right without thinking. I don't.
> Reading your text, I note the following peculiarities you have to be
> aware of in Firebird and not in SQL Server:
>
> 1. You add "+0" or "|| ''" to avoid using unappropriate indices.
>
> 2. Previously you avoided "in <subselect>". Luckily this quirk seems to
> have been resolved now.
>
> 3. For low selectivity indices you add the PK column to the index.
>
> So far I have not had any problems with SQL Server using indices in a
> counter productive way, like Firebird often does when low selectivity
> indices are present. So neither point 1 nor point 3 is an issue for SQL
> Server.
>
> I have not had any problems with "in <subselect>" with SQL Server, so
> point 2 is not an issue there either.
>
> I'm not saying these problems would be easy to solve in Firebird, nor am
> I saying that I know how to solve them. And I'm sure SQL Server has its
> quirks too - I just haven't stumbled upon them yet.
>

However SQLServer does have issues, every database has it's quirks, for
most situations, a generic SQL is going to work fine, and without many
problems, even with Firebird. The best way to deal with these kinds of
issues is to make copious use of views. Then you simply need to deal
with showstoppers. For example if you have a Linux or Solaris shop,
SQLServers biggest issue is that it doesn't run on either.

> But what I'm saying is that for a developer who has to write
> applications that support different servers (and so can't spend weeks on
> learning all the peculiarities of every server he's going to support),
> Firebird stands out as the one causing most problems regarding query
> performance. This is a real problem that I believe is stopping Firebird
> from becoming more successful than it is.

Personally I have always written an application to deal with a specific
database, which allows the DBA and programmer to deal with coding, and
not trying to write their application to work perfectly on everything.
Applications that try to run on anything, often end up a
Jack-of-all-trades who is master of none. In other words, it may run on
anything, but doesn't run well on any.

I once saw a SQLServer performance hole, 20,000 record select, it
started running on Friday at 4:55PM, was still running Monday Morning at
9:15 when we pulled the plug.

W