3 ms·
I've seen things written in Oracle 20-30 years ago that I've still not seen PostgreSQL or SQL Server do. An example? A full credit card processor in stored pro
by buro9 4y ago
I've seen things written in Oracle 20-30 years ago that I've still not seen PostgreSQL or SQL Server do.
An example? A full credit card processor in stored procs. I really mean full, it handled the call outs to financial providers, managed the 2-phase commit, replied to the app, all within a single call (Stripe API is the closest I've seen to this in the 30 years since).
It remains possible to do things that are crazy and powerful, very quickly.
Whether the people here would want to is a different question. But if you are in a large corp and Oracle is available it is easy to do crazy things.
Once these things are done, Oracle is going nowhere. They are now in your system for the life of your product.
- icedchai 4y agoOracle does have quite an impressive set of capabilities. However, for every company that absolutely needs Oracle, there are probably 10+ that don't and could work fine with PostgreSQL or SQL Server today (though maybe not 20 years ago.) I worked in an Oracle shop early in my career, and would never want to go back to that again.
- sprayk 4y agoCurious: what is the version control story like for stored procs? The two that naively come to mind would be 1. Organized in some regular repo with some tooling to deploy/sync 2. Some way of tracking versions _in a DB_ and some magic set of queries that can deploy from said DB.
- zaphar 4y agoNot only could you do that in Postgres, but you could do it in a real language of your choice. The reason you don't see it done is because the people who choose Postgres over Oracle know that it's kind of a terrible way to build it if you care about long term maintainability. That method of building fossilizes quicker than quickcrete.