DB conversion

[CLIFFORD ILKAY]

At 11:57 23/10/2003 -0400, Tim Writer wrote:
>cbbrowne-HInyCGIudOg at public.gmane.org writes:
>
> > > Is there an easy way to convert from Postgres to MySQL?
> >
> > There can't be, because a great deal of the functionality would require
> > that you add substantial code to your application since MySQL does
> > minimal if any validation of input, and does not support vital features
> > such as triggers, stored procedures, and VIEWs.
> >
> > The only way you are likely to be able to convert a relational database
> > application to use MySQL is if you are using your database in the most
> > impoverished way.
>
>At risk of starting a flame war, that's a matter of opinion.  I could rewrite
>your last sentence this way:
>
>     You can easily convert your application from Posgress to MySQL
>     as long as you're using it sensibly, i.e. for storing data. If
>     you're using "advanced" features that really don't belong in a
>     database, like triggers, stored procedures, etc. the conversion
>     will be more difficult.

That is also a matter of opinion. I think triggers and SPs are pretty 
useful things as they allow me to enforce data integrity at the DB engine 
level, where it should be enforced, so that people who don't know any 
better, or malicious people, do not mess up the database. Non trivial 
database applications typically are not converted to different databases 
anyway so that is a red herring. It seems to me that the database vendors 
who do not have stored procedures and triggers seem to push the portability 
thing the hardest claiming that using these features in their competitors' 
products will lead to vendor lock in. The reality is that no matter where 
the rules are implemented, you are going to be locked into one thing or 
another. If you implement those rules at the application layer, regardless 
of the language or product you use, chances are, you will be locked in to 
that language or product so how does that help with this supposed 
requirement for ease of conversion?

It is quite common for organizations that use an RDBMS to use various 
languages and tools to work with that database. I have seen VB, C, and 
OMNIS code all using the same Oracle database. Fortunately, the DBA had 
enough sense to grant execute privileges on the stored procedures and 
functions only and did not grant insert, update, and delete privileges on 
the tables referenced by those objects. You can bet that had the DBA not 
done that, the rules would have been implemented at least three different 
ways by the three different developers or development teams. Business rules 
change. It helps to enforce rules in one place to avoid the need to check 
all the different places that business rules could be implemented in the 
absence of server side code.

>When all you've got is a hammer, everything looks like a nail.

The same could be said of MySQL. MySQL is a fine file manager. I just 
wouldn't call it a database yet:) I use it but certainly not for anything 
that could be termed "mission critical".

Regards,

Clifford Ilkay
Dinamis Corporation
3266 Yonge Street, Suite 1419
Toronto, Ontario
Canada M4N 3P6

Tel: 416-410-3326

mailto:clifford_ilkay-biY6FKoJMRdBDgjK7y7TUQ at public.gmane.org  

--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml