Re: I can't get logged into the new improved metalink...
From: The Boss <usenet_at_No.Spam.Please.invalid>
Date: Sat, 14 Nov 2009 01:33:07 +0100
Message-ID: <4afdfac5$0$12223$e4fe514c_at_dreader26.news.xs4all.nl>
Palooka 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.
Date: Sat, 14 Nov 2009 01:33:07 +0100
Message-ID: <4afdfac5$0$12223$e4fe514c_at_dreader26.news.xs4all.nl>
Palooka wrote:
> 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. >
Your 5-minute review must have been a couple of years ago, because MySQL supports foreign key constraints and referntial integrity for at least 4 years (with the InnoDB engine), see for instance this article: http://articles.techrepublic.com.com/5100-10878_11-6035435.html
I wouldn't use MySQL for critical apps either, but for a non-critical intranet portal it isn't that bad.
-- JeroenReceived on Fri Nov 13 2009 - 18:33:07 CST