Forum OpenACS Q&A: Response to nsjava staus

59: Response to nsjava staus (response to 1)
Posted by Andrew Piskorski on
Incidentally, while supporting more databases (e.g, MS SQL Server) for OpenACS is very cool from a gee-whiz technical achievement point of view, in practice, it's hard for me to imagine why anyone would do it for any practical technical (as opposed to marketing) reason.

OpenACS has Oracle, the market and capability leading closed-source database. OpenACS has PostgreSQL, the market and capability leading open-source database. OpenACS already has the two best databases from both worlds, why would anyone want to invest a huge effort to instead use an inferior database?

The only entirely rational technical reason I can imagine is someone with a large committment to a legacy app using a different RDBMS (Sybase or MS SQL Sever, say), and their new OpenACS installation must, for some hypothetical reason, directly run OpenACS in the same database as their legacy app. Which sounds pretty far fetched to me... Particularly since most organizations integrating OpenACS into a large legacy app would probably insist on using an entirely serparate database installation for OpenACS, be it Oracle, Postgres, Sybase, or whatever.

Or perhaps there's the, "Our vast huge company uses only database X, we don't want to have to even think about ever supporting any other database" argument. But supporting a port of OpenACS sounds like much more work than simply learning to use Postgres, or even Oracle for that matter. So is that a valid or a specious argument?

John, you know more about this than me. As long as we're already off-topic, I'm curious, does some big organization porting OpenACS to a new database really make sense from a hard-headed IT management point of view? Or is it solely a potentially critical tool to get in the door and pitch the OpenACS solution to, ah, less than entirely hard-headed IT managers and staff? Or somewhere in between?