Re: I can't get logged into the new improved metalink...

> On Nov 12, 11:08 pm, Tim X <t..._at_nospam.dev.null> wrote:
>
>>
>> I have yet to test some of the more 'enterprise' oriented aspects of
>> postgresSQL, but am hoping to get the opportunity soon. At this sage,
>> I'm still trying to convince people that while postgresSQL is not a
>> simple drop in replacement, there are applications which will do fine
>> using it. On the other hand, I'm more skeptical regarding any
>> application that demands really high throughput with large data
>> sets. The real problem is convincing management that maintaining two DB
>> engines and using each when appropriate may actually provide a better
>> and cheaper solution than a 'use Oracle for everything' attidue that
>> currently prevails.
>>
>
> As someone who spent a lot of years dealing with multiple db engines,
> I must say, this "when appropriate" idea breaks down way too soon.
> Eventually, people either start going the db-blind bit-bucket route,
> or one becomes the stepchild. "Better and cheaper" is one of those
> things that can be misapplied to a set of system life cycles.
>

I agree you need to be careful and you probably need to define som eclear criteria regarding when to use one or the other and yes, you do need to be careful that one doesn't become the 'poor stepchild'. However, the reality for us right now is that Oracle for everything is just not working. Part (a big part) of the problem is lack of funding for skilled developers with good Oracle experience and part of the problem is a lack of DBA resources.

To some extent, the problem is made worse because som eof the apps that are currently using Oracle are already viewed/treated by the DBAs as being insignificant or irrelevant compared to the 'important' systems. The reality is that these smaller applications are actually just as critical. So, we already have poor stepchildren, but its the database apps rather than the engine. Combine this with a lack of DBA resources and the result is we cannot get crucial upgrades, improves and fixes done in a timely manner.

On the other hand, the couple of systems we now have running on postgresSQL are doing really well. The reduced complexity has meant that our Unix admins are able to administer the system quite adequately. This has taken som eload off the Oracle DBAs while also providing developers and clients with better responsiveness.

How it pans out in the long term only time wil tell.

> Ironically, this was one of the reasons I went whole-hog towards
> Oracle - only to become more valuable to places that were adding
> Oracle to a mix of engines.
>

In a similar vain, I've developed using Oracle for quite some time because I thought it was the best engine out there, was going to be around for a long time and would provide good opportunities.

I'm a little less confident now and think its probably even more important, from a developer perspective, to stay across a wider range of technologies and not become too specialised or focused on just a small segment.

Tim

-- 
tcross (at) rapttech dot com dot au