Actually, this was a fundamental and known weakness in the SQL Server
2000 transactional model, being more like DB2 than Oracle.
I disagree. First off, we're talking about the DEFAULT transactional model,
locking mode, and where new records are placed. It has always been
posssible to tweak any of the databases to the other's transactional model.
Second of all, it was not a weakness -- it was a deliberate choice of
optimization -- it was a choice of OLAP over OLTP (and, let's be honest, for
most databases on limited memory machines with low OLTP requirements, this
was the correct choice until ballooning memories made the reverse true).
Because PostgreSQL has used the same kind of model as Oracle -- and for a
very long time -- it has always been relatively strong at OLTP
throughput. Until SQL Server 2005, the Microsoft offering was never
really competitive.
Bull. For anything except the heaviest OLTP loads, Microsoft was more than
adequate. You don't need a semi to drive the highways.
It had little to do with development timelines. On the other hand,
PostgreSQL was a bit of a dog at OLAP until relatively recently.
See? You're making my point. :-)
You imply that the performance is due to some kind of linear development
path, but in fact SQL Server 2005 changed its internal model to be like
Oracle and PostgreSQL so that it could be competitive at OLTP. It is a
matter of algorithm selection and tradeoffs, not engineering effort. SQL
Server (until two years ago) has always had relatively poor lock
concurrency, but gave very good baseline OLAP performance as a
consequence of that decision. The reality is that it is much easier to
make the Oracle/Postgres model perform satisfactorily at OLAP than to
make the old SQL Server model perform satisfactorily at OLTP.
Again, you're making my point. Until memory became cheap and OLTP become
more critical, Microsoft made the right choice of OLAP over OLTP. When the
world changed, so did they. I'd call that a strength and flexibility, not a
weakness.
I've worked with very large databases on several major platforms,
including Oracle and SQL Server in many different guises. Oracle's
parallel implementation may not distribute that well, but that is because
traditional transactional semantics are *theoretically incapable* of
distributing well. To the extent it is possible at all, Oracle does a
very good job at making it work.
So, is your claim that Oracle distributes better than Microsoft? If so,
why?
There are new transactional architectures in academia that should work
better in a modern distributed environment than any of the current
commercial adaptations of classical architectures to distributed
environments.
And PostgreSQL will probably implement them long before Oracle or MS.
Sun Microsystems not only officially supports it, they do a lot of
development on it, as does Fujitsu in Asia, Red Hat and a few other large
companies that are heavily invested in it. A significant portion of the
main PostgreSQL developers do it as their official corporate job.
Cool. I wasn't aware that it had made that many inroads. Awesome.
PostgreSQL is very broadly ANSI compatible (including a lot of ancillary
database standards surrounding SQL), and to the extent it has a "flavor"
it clearly borrows from Oracle rather than SQL Server. SQL Server has a
lot of bits that do not conform to standards that everyone else supports.
From a historical perspective, PostgreSQL shares a transaction model with
Oracle, started on Unix, and has been around since a time when SQL Server
was not something you would want to emulate. PostgreSQL has matured to
the point where it mostly follows standards to the extent possible but
has enough unique features and capabilities that it has started to become
a flavor of its own.
If you could swap out an MS-SQL server *immediately* for a PostgreSQL
server simply by copy the data and rebinding a WINS name or an IP
address, I would be in hog heaven even if support wasn't absolutely
guaranteed since I could always switch back. Given that there's a huge
transition cost (changing scripts, procedures, etc.), I can't get *ANY*
agreement for the thought of switching (and I'm sure that there are
*MANY* more in my circumstances).
The only corporate database that relatively easily ports back and forth
with PostgreSQL is Oracle. Nonetheless, a number of people have ported
applications to PostgreSQL from MS-SQL with good results; questions about
porting nuances come up regularly on the PostgreSQL mailing lists.
Beyond your basic ANSI compliance, database portability only sort of
exists. Inevitably people use non-standard platform features that expose
the specific capabilities of the engine being used to maximize
performance. As a practical matter, you pick a database platform and
stick with it as long as is reasonably possible.
J. Andrew Rogers
-------------------------------------------
agi
Archives: http://www.listbox.com/member/archive/303/=now
RSS Feed: http://www.listbox.com/member/archive/rss/303/
Modify Your Subscription:
http://www.listbox.com/member/?&;
Powered by Listbox: http://www.listbox.com
-------------------------------------------
agi
Archives: http://www.listbox.com/member/archive/303/=now
RSS Feed: http://www.listbox.com/member/archive/rss/303/
Modify Your Subscription:
http://www.listbox.com/member/?member_id=8660244&id_secret=101455710-f059c4
Powered by Listbox: http://www.listbox.com
