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

From: Tim X <timx_at_nospam.dev.null>
Date: Sat, 14 Nov 2009 17:07:46 +1100
Message-ID: <87bpj5tz9p.fsf_at_lion.rapttech.com.au>

Palooka <nobody_at_nowhere.invalid> writes:

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

I think it can do foreign key constraints, but this depends on the storage engine you configure. This is one of the tricky aspects of MySQL. It supports a couple of different storage engines which have quite different characteristics. Generally, the default engine is the one that shows really fast queries. However, it uses table locks for inserts/updates, so as soon as you add those to the mix, performance falls right off. If you want more of the 'normal' sor tof RDBMS facilities, you need to go with other storage engines, but then its a whole different set of trade-offs.

Apart from referencial integrity issues, I've also found MySQL a pain with respect to SQL, especially for things like sub-queries etc. Stored procedures, while supported can be a pain to implement as well. I've also run into a number of clients with problems arising from currupted databases. Admittedly, not for a while because I've been focused on Oracle, but before moving to Oracle, data curruption was a real problem.

Tim  

-- 
tcross (at) rapttech dot com dot au

Received on Sat Nov 14 2009 - 00:07:46 CST