Andrew, what would you guys ngals think of having to move to postgres soonish?
Not going to happen, not anytime soon, and maybe never, for a variety
of reasons.
Folks, keep in mind that we don't use our RDBMS just for a
website, and I suspect this is pretty common for other small firms out
there.
In our particular case, we use Oracle extensively for other
non-OpenACS non-web data management. We take advantage of OpenACS to
view, help maintain, etc. that data. Essentially, in addition to the
other ways we use it OpenACS provides a UI to that data. It all lives
in the same Oracle instance, in different table spaces.
When we were starting with this back in 2001, PostgreSQL wasn't quite
ready for our needs and ACS/OpenACS 4.x didn't yet support PostgreSQL
anyway. I'm told that PostgreSQL now supports the SQL:2003 OLAP
(windowing, lead/lag, etc.) features, which are incredibly useful when
dealing with financial and other time-series data. So if we were
starting from scratch today, perhaps we'd go with PostgreSQL rather
than Oracle. But not necessarily, it depends.
Many third parties - like data vendors - still support Oracle but not
PostgreSQL in ways that can matter. E.g, in my experience most data
vendors essentially just give you obnoxious, giant, completely
de-normalized CSV files. The better ones (or perhaps the
ones with the most complicated data) pre-specify a reasonable
relational schema, and often provide their own loader tool to keep it
updated. We use one which only supports Oracle and MS SQL
Server. (Could they add support for PostgreSQL if they wanted to, or
even SQLite? Probably, but so far they haven't.)
With a data vendor like that, do you have to use their
loader? Often, no, but if you don't, you get to handle all
the work of processing their internal-format transactional update
files multiple times every day, etc. etc. None of that is
insurmountable. But it is an example of why it is valuable to have a
nice toolkit that just so happens to support the RDBMS that you also
want to use for other reasons.
Should you care about this? About our specific needs, perhaps not.
But I hope it least illustrates how the "legacy" feature of good
support for both Oracle and PostgreSQL may be of more value than the
typical PostgreSQL-only OpenACS user appreciates.
By the way, Oracle has ended up working well for us, but we
didn't know that it would ahead of time, nor could we have,
since we didn't even know many of the details of our own needs yet.
(Heck, I didn't even know that lead, lag, and all the other SQL:1999
and SQL:2003 OLAP functions existed
until 2001,
and now we critically depend on them.)
In that situation, which I think is pretty common, the right approach
is to bias your choice of tools towards flexibility. So which would
sound like a better bet to you? "We only support one RDBMS,
period." Or, "We support two of the most powerful and full-featured
RDBMSs available, PostgreSQL and Oracle."
Back then, I was certainly thinking about the fact that if we
ran into some unexpected major roadblock with Oracle, we might be able
to get around it with PostgreSQL. The same feeling in the opposite
direction might be more common.
