Re: I can't get logged into the new improved metalink...
From: Palooka <nobody_at_nowhere.invalid>
Date: Fri, 13 Nov 2009 23:36:10 +0000
Message-ID: <O3mLm.38947$s_4.13981_at_newsfe02.ams2>
On 13/11/09 07:08, Tim X wrote:
> Palooka<nobody_at_nowhere.invalid> writes:
>
>> On 12/11/09 21:14, Mladen Gogala wrote:
>>> On Thu, 12 Nov 2009 11:50:25 -0800, justalowlydba wrote:
>>>
>>>
>>>> Is there a solution for this problem as I would like to get this
>>>> resolved?
>>>
>>> There is no solution which doesn't include the use of firearms.
>>
> Personally, I prefer knives - its more personal!
>
>>
>>>
>>>
>> Like Gerard, I am looking at PostgreSQL. Seems easy as pie so far.
>>
>
> PostgresSQL is pretty good. I've moved a couple of fairly simple apps
> from Oracle to PostgresSQL and it has been fairly straight
> forward. However, I've only been using the basic postgresSQL, not the
> 'special' one that is specifically aimed at being an Oracle replacement
> (I believe you can get it with support etc). I also know there are some
> Oracle compatibility 'plugins', but I've not used them either.
>
> On the whole, I've found no really difficult to resolve issues and I
> find postgresSQL magnitudes better than MySQL, which IMO is only good
> for web counters and basic bit bucket style database apps, which I tend
> to avoid where possible.
>
> 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.
>
> What I'd really like to try is a mid sized app that has quite high
> inserts/updates along with the need for fast queries. I've found MySQL
> pretty woeful in this regard. Fro the little experience I've had so far
> with postgresSQL, you do need to be more across locking issues. I also
> find the available tools for analysis and identifying possible tuning
> strategies a little limited, though to be honest, I've not really needed
> them. Its more the desire to have a good feel for what is going on and
> that will probably come with time.
>
> I also find the support for using different scripting languages pretty
> interesting, though I've not yet determined what the trade-offs are with
> the different optons available. What I really do like is that it is a
> more complete, in the sense of what I'm use to, RDMS. I was constantly
> frustrated with MySQL's inability to do things which I've grown
> accustomed to being what you would find in a RDBMS.
>
After a five minute review, I concluded that MySQL was not an option. If I understand right, it doesn't even support foreign key constraints.
Date: Fri, 13 Nov 2009 23:36:10 +0000
Message-ID: <O3mLm.38947$s_4.13981_at_newsfe02.ams2>
On 13/11/09 07:08, Tim X wrote:
> Palooka<nobody_at_nowhere.invalid> writes:
>
>> On 12/11/09 21:14, Mladen Gogala wrote:
>>> On Thu, 12 Nov 2009 11:50:25 -0800, justalowlydba wrote:
>>>
>>>
>>>> Is there a solution for this problem as I would like to get this
>>>> resolved?
>>>
>>> There is no solution which doesn't include the use of firearms.
>>
> Personally, I prefer knives - its more personal!
>
>>
>>>
>>>
>> Like Gerard, I am looking at PostgreSQL. Seems easy as pie so far.
>>
>
> PostgresSQL is pretty good. I've moved a couple of fairly simple apps
> from Oracle to PostgresSQL and it has been fairly straight
> forward. However, I've only been using the basic postgresSQL, not the
> 'special' one that is specifically aimed at being an Oracle replacement
> (I believe you can get it with support etc). I also know there are some
> Oracle compatibility 'plugins', but I've not used them either.
>
> On the whole, I've found no really difficult to resolve issues and I
> find postgresSQL magnitudes better than MySQL, which IMO is only good
> for web counters and basic bit bucket style database apps, which I tend
> to avoid where possible.
>
> 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.
>
> What I'd really like to try is a mid sized app that has quite high
> inserts/updates along with the need for fast queries. I've found MySQL
> pretty woeful in this regard. Fro the little experience I've had so far
> with postgresSQL, you do need to be more across locking issues. I also
> find the available tools for analysis and identifying possible tuning
> strategies a little limited, though to be honest, I've not really needed
> them. Its more the desire to have a good feel for what is going on and
> that will probably come with time.
>
> I also find the support for using different scripting languages pretty
> interesting, though I've not yet determined what the trade-offs are with
> the different optons available. What I really do like is that it is a
> more complete, in the sense of what I'm use to, RDMS. I was constantly
> frustrated with MySQL's inability to do things which I've grown
> accustomed to being what you would find in a RDBMS.
>
After a five minute review, I concluded that MySQL was not an option. If I understand right, it doesn't even support foreign key constraints.
No referential integrity, then. If I just wanted a bit bucket, I might just as well store the data in flat text files.
Palooka Received on Fri Nov 13 2009 - 17:36:10 CST