http://www.perlmonks.org?node_id=585936


in reply to Re^2: DBD::Oracle faster with bound sql than stored procedures?
in thread DBD::Oracle faster with bound sql than stored procedures?

Why on Earth would I swap my RDBMS? Well, because IBM or MS or whomever offered a much better deal. I've heard that these companies (including Oracle, of course) compete quite a bit ;-)

What you do now can seriously impact how easy it is to switch, should your non-technical management decree it. If you take advantage of Oracle-specific functions, you can drastically speed up your queries, speed up your development, and hurt your ability to switch should the need arise. Kind of a trade-off.

Personally, though, while I understand the concept and need for the ability to switch, I'd still go with whatever gave me the maximum benefit under the current infrastructure, without impacting maintainability in a negative way, and then tell management what the costs were to switch our application for when other sales guys approach them to get us to switch. It still may come out as a benefit to switch because the switch itself is a one-time charge, while the licensing and support is an ongoing charge.

  • Comment on Re^3: DBD::Oracle faster with bound sql than stored procedures?

Replies are listed 'Best First'.
Re^4: DBD::Oracle faster with bound sql than stored procedures?
by Jonathan (Curate) on Dec 04, 2006 at 12:26 UTC
    The cost of database licenses is a relatively minor component in the total cost of the whole project. If you have a pool of Oracle developers who understand your application and business then you're pretty well locked in.

    Again, this is from a large project/large corporation perspective.

Re^4: DBD::Oracle faster with bound sql than stored procedures?
by nanotasher (Novice) on Jul 09, 2008 at 15:44 UTC
    That seems a little silly to me. Hypothetically speaking, of course.. If I bought Oracle, then MS offered me a better deal, I'd have sunk costs from buying Oracle. It wouldn't make any sense to switch to Oracle. I think the nightmare of transporting the data from one database to another more than offsets the nightmare of tying yourself to a vendor's stored procedure methods (which, by the way, exist in all major RDBMS software).