Re: postgre-sql to mysql translation?

[Richard Ellis <..hidden..>]

On Sat, Oct 07, 2006 at 06:20:48PM -0400, m o wrote:
> hi,
> 
> here's a suggestion . . . ever think of porting this to mysql? with
> the rise of crm's like sugarcrm, the need for a mysql-based
> accounting program has never been greater. sure, we can save the
> data from mysql to postgre-sql, but it seems in inelegant solution.
> a shift to mysql would make this program even more mainstream. just
> a suggestion . . . thanks for reading.
> 
> mike

Actually, if you are a corporation that puts it's financial data into
mysql, then it deserves the extreme audit reaming that it will
receive at some point in the future:

MySql gotchas:
http://sql-info.de/mysql/gotchas.html

The scary ones from a financial perspective are:

1.11 (division by zero).  Dividing by zero in a financial app should
generally be an indication of something wrong somewhere, yet 1.11
shows that mySql will just return null and keep on going, never
telling you that you had a severe problem.

1.13. (What goes in - isn't (always) what comes out) - You can't
trust the numbers in a DB when you insert a value that you've told it
should be too big, and it instead silently inserts the largest legal
value for you.  If you've told it the value should be too big, then
it's too big, end of story.

1.14. (February 31st) - Can you imagine an auditor or the IRS (if you
are in the USA) looking at sales or reciepts on Feb. 31st and
wondering just when in the calendar this date came from?  That's sure
to get you very "extra special" treatment, which you definetly do not
want.

The remainder of the gotcha's are all just as bad from a data
integrety perspective, but these three are probably the most
troublesome for a finance application.