4 ms·

Yes, Oracle's database is really very, very good, and if you know how to use it it's really powerful. I really did like working with it, but hope I never will

by nemo 11y ago

Yes, Oracle's database is really very, very good, and if you know how to use it it's really powerful. I really did like working with it, but hope I never will again due to the company that sells it. While Oracle is powerful (and fast and scalable and feature-rich), if you get to know another enterprise RDBMS in depth you'll find that once you start leveraging vendor-specific features you'll get more power as well (perhaps not as much as Oracle, but still quite a lot), at the expense of vendor lock-in. Using an ORM or other abstraction layer to be DB agnostic for some businesses would be a better financial choice, since once Oracle's burned you, you can burn your bridges and walk away to something that might be technically less powerful, but will probably save you a lot of money. Vendor lock-in has its own costs. It depends on your scale and your plans to scale. Running large scale enterprise apps Postgres might be very risky (Postgres is getting better, though), but DB2 or another alternative might work as well and give you some leverage when the Oracle audit thugs come in to extort more money from you. While I know I am biased, I sincerely believe that Oracle the company is a money grubbing monstrosity that acts effectively as an extortionist to their customers (they aren't alone here, but stand out to the degree they push the envelope of greed, they're a good 10 years ahead of the competition). They ruined Sun/Solaris, they ruined MySQL (letting it wither when it could be much further along by now), they are doing very dubious things with Java, they hosed OpenOffice, and I need to stop at PeopleSoft because my blood pressure is raising - and are pretty much trying to be the MS of the 90s in the markets they are in, and being in a position to be able to walk away from a business like that is a very practical business decision.

gaius 11y ago
My belief is if you can feasibly write your app with an ORM then you should just use Postgres. If you can't, because you need $feature that the ORM doesn't manage, then buy the most powerful database you can afford and actively look for opportunities to exploit every bit of the functionality that you've paid for. The truth is being database agnostic is wildly overrated; in practice any organization will go through 10 languages before they decide to change their database, and no-one in their right mind cares about designing an app that is "language agnostic". You wouldn't start out in a language that supports, I dunno, closures, then deliberately not use them just in case you wanted to switch to another language in a couple of years.
- kbenson 11y ago
  That's a good point, and I mostly agree with it, but it's less true now than it was in the past. There's plenty of shops that switch around data stores for part of all of their data now. It may not be all that common to go from one SQL variant to another, but there are plenty of cases of people moving from SQL to NoSQL (and back or vice-versa). Think BigTable, Dynamo and Cassandra. That said, there's as little hope of being database agnostic in those situations as there is being language agnostic. Really, being SQL variant agnostic is like trying to make sure you stay away from language features that you can't rely on if you switch between a C/C++ implementation and JVM hosted implementation of the same language. It's relatively easy (in the context of what we are discussion in this conversation at least), and as such may be feasible to take advantage of the flexibility it gives you later.
  - gaius 11y ago
    Perhaps a better example would be avoiding multiple inheritance not because you think MI is a bad idea but just in case you wanted to switch from C++ to Java in the future and you might need to re-architect.
    - kbenson 11y ago
      Maybe, but I think it might be more apt to say "just in case you wanted to switch from C++ to Java in the future and you would prefer not to to re-architect." IMO I think this is mostly an enterprise (or a "we serve enterprises") sort of mindset, where they have existing, vetted systems, and being able to match those targets opens you up to more of the market. Is their code target C/C++ or the JVM? Is their target DB Oracle, DB2 or MSSQL. I can imagine having an app that could be deployed on both Oracle and MSSQL back-ends would greatly increase your markets due to ease of getting it vetted in some organizations, just as I can imagine not too far in the distant past having both JVM and C/C++ versions might have done the same (but I thing that's still inherently harder to do).
throwawaykf05 11y ago
While I agree with your technical views, just calling out a few unfair statements about the companies mentioned: 1. Microsoft certainly was aggressive with their competition in the 90s (and still are), but they've never been hostile to their customers, at least nowhere as much as Oracle. 2. Java has progressed much faster under Oracle than it ever did under Sun, and most people will agree they're doing that right, at least. If by "questionable" you mean the copyright lawsuit, consider that a) so far they seem to be legally in the right, and b) it was Google that did the questionable thing by ripping Sun off in the first place.
- Oletros 11y ago
  > and b) it was Google that did the questionable thing by ripping Sun off in the first place. This is something I have never understood about the trial. Google used Apache Harmony implementation, does it means that the ones ripping off Sun was Apache Foundation?
  - throwawaykf05 11y ago
    Really late reply, but apache also did not have a proper license from Sun: https://en.wikipedia.org/wiki/Apache_Harmony#Difficulties_to_obtain_a_TCK_license_from_Sun https://en.wikipedia.org/wiki/Apache_Harmony#Difficulties_to...

by nemo 11y ago

gaius 11y ago

My belief is if you can feasibly write your app with an ORM then you should just use Postgres. If you can't, because you need $feature that the ORM doesn't manage, then buy the most powerful database you can afford and actively look for opportunities to exploit every bit of the functionality that you've paid for. The truth is being database agnostic is wildly overrated; in practice any organization will go through 10 languages before they decide to change their database, and no-one in their right mind cares about designing an app that is "language agnostic". You wouldn't start out in a language that supports, I dunno, closures, then deliberately not use them just in case you wanted to switch to another language in a couple of years.

kbenson 11y ago
That's a good point, and I mostly agree with it, but it's less true now than it was in the past. There's plenty of shops that switch around data stores for part of all of their data now. It may not be all that common to go from one SQL variant to another, but there are plenty of cases of people moving from SQL to NoSQL (and back or vice-versa). Think BigTable, Dynamo and Cassandra. That said, there's as little hope of being database agnostic in those situations as there is being language agnostic. Really, being SQL variant agnostic is like trying to make sure you stay away from language features that you can't rely on if you switch between a C/C++ implementation and JVM hosted implementation of the same language. It's relatively easy (in the context of what we are discussion in this conversation at least), and as such may be feasible to take advantage of the flexibility it gives you later.
- gaius 11y ago
  Perhaps a better example would be avoiding multiple inheritance not because you think MI is a bad idea but just in case you wanted to switch from C++ to Java in the future and you might need to re-architect.
  - kbenson 11y ago
    Maybe, but I think it might be more apt to say "just in case you wanted to switch from C++ to Java in the future and you would prefer not to to re-architect." IMO I think this is mostly an enterprise (or a "we serve enterprises") sort of mindset, where they have existing, vetted systems, and being able to match those targets opens you up to more of the market. Is their code target C/C++ or the JVM? Is their target DB Oracle, DB2 or MSSQL. I can imagine having an app that could be deployed on both Oracle and MSSQL back-ends would greatly increase your markets due to ease of getting it vetted in some organizations, just as I can imagine not too far in the distant past having both JVM and C/C++ versions might have done the same (but I thing that's still inherently harder to do).

throwawaykf05 11y ago

While I agree with your technical views, just calling out a few unfair statements about the companies mentioned: 1. Microsoft certainly was aggressive with their competition in the 90s (and still are), but they've never been hostile to their customers, at least nowhere as much as Oracle. 2. Java has progressed much faster under Oracle than it ever did under Sun, and most people will agree they're doing that right, at least. If by "questionable" you mean the copyright lawsuit, consider that a) so far they seem to be legally in the right, and b) it was Google that did the questionable thing by ripping Sun off in the first place.

Oletros 11y ago
> and b) it was Google that did the questionable thing by ripping Sun off in the first place. This is something I have never understood about the trial. Google used Apache Harmony implementation, does it means that the ones ripping off Sun was Apache Foundation?
- throwawaykf05 11y ago
  Really late reply, but apache also did not have a proper license from Sun: https://en.wikipedia.org/wiki/Apache_Harmony#Difficulties_to_obtain_a_TCK_license_from_Sun https://en.wikipedia.org/wiki/Apache_Harmony#Difficulties_to...