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 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:
> 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

Original text of this message