Forum OpenACS Development: Re: Towards OpenACS 5.9
All recent development on OpenACS passed through the uneasy task of considering Oracle people still around, so it would be better if such struggle could end up useful.
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.
None, is my guess.
Back when I was maintaining Oracle support, did you ever offer to help pay for my time? Or, when the subject was ever raised, did you just post as you have posted now: "we need oracle support, don't drop it!"
"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."
Sure, valuable to you and other freeloaders. But the reality is that for over a decade, almost all of the financial and programmer resource support has come from those using PG.