Mono, gcj, java, c++, what?

[david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org (David Kramer)]

On 08/29/2010 04:36 PM, Mark Woodward wrote:
> On 08/29/2010 02:42 PM, Dan Ritter wrote:
>> That leaves MySQL and Postgres, for SQL databases, and a whole
>> host of non-SQL systems of various sorts. No matter what you
>> start with, you may want to change it later on. Stored
>> procedures will make that a nasty pain.

While there are SQL differences between different DBMSs, they don't
compare to the differences in how stored procedures are done in
different DBMSs.  I've worked on products that had to support multiple
DBMSs at the same time, and keeping them in sync was nearly impossible.
 It's an even harder problem than localization with different language
files (which I've also done).

My big problem with relying that heavily on stored procedures, from a
software engineering point of view, is that you're moving code into an
environment not really designed for software development.  It becomes
much harder to ensure that the code that should be running is running,
what revision in source control it came from, etc.

It also means (to the best of my knowledge) that the source is in the
database and may be seen by the customer or someone else you don't want
to see it.  So for making queries faster it may be OK, but I wouldn't
put too much business logic in there,

> Only if you want to switch databases mid-stream, and no database will be 
> without problems. It is virtually impossible to go from MySQL to a real 
> database without re-writing tables and writing a data reformatter to 
> take MySQL database extracts and load them into something else. Some 
> NoSQL to SQL or some other system, isn't going to be pretty.

There are other solutions to these problems, like using Hibernate/JPA or
other persistence layer that takes care of the dialect differences for you.

PS: Nice to see a software development discussion on here for a change.