Re: I can't get logged into the new improved metalink...
From: Palooka <nobody_at_nowhere.invalid>
Date: Sat, 14 Nov 2009 02:19:35 +0000
Message-ID: <%soLm.96162$9M4.57682_at_newsfe03.ams2>
On 14/11/09 00:33, The Boss 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.
I stand corrected, then; thanks. However, for now I shall continue to check out PostgreSQL.
Date: Sat, 14 Nov 2009 02:19:35 +0000
Message-ID: <%soLm.96162$9M4.57682_at_newsfe03.ams2>
On 14/11/09 00:33, The Boss wrote:
> 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. >
I stand corrected, then; thanks. However, for now I shall continue to check out PostgreSQL.
Palooka Received on Fri Nov 13 2009 - 20:19:35 CST