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

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

On 08/30/2010 10:54 AM, Eric Chadbourne wrote:
>> 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.
> 
> I don't see how it's any harder than normal.  Last year I worked for a
> company that had tens of thousands of lines of code in pl/sql and it
> worked fine.  Simple language too.  Easy for the tech support team to
> troubleshoot.

OK.  And when tech support tweaks the script, how do you do a diff to
see what's changed so you can duplicate it during an upgrade?  When
things don't work, how do you know what the last tech support person did
to their scripts?

> I personally like the separation from the front end.

What are you calling the front end here?  This is web-based Java, so
we're talking, at the very least, the client (browser), the web services
(JSPs, faces, servlets, HTML pages, etc), and the database.  Optionally
tag on Flex in between the browser and the web services, and a
persistence layer between Java and the database.

> Aren't stored procedures faster and a bit more secure?

If you're talking queries, maybe.  It depends on the amount of
processing vs the amount of data coming back.  Sending the join of two
tables is not likely to be significantly faster.  Complex group by and
nested queries make it more of a win.  However, there's an awful lot of
application that's business logic.  Shoving that in the database can
slow things down, and makes scaling hard (you can load balance dozens of
web servers, but running multiple DBMS instances and replicating between
them is a much harder problem).

>> 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,
> 
> Oracle has some scheme to obfuscate the code.  I'm not sure how it works
> as I didn't need it.  But hey, it's a good thing people can see the
> code.  :)

It's a good think if you're talking open source code.  It's a bad thing
if the code is closed source and your bread and butter, trade secrets,
or even exposing interfaces that should not be accessed directly.

> It's a neat thought experiment.  I would vote for two white boxes,
> Gnu/Linux, Apache, PostgreSQL and PHP.  Put all business logic in stored
> procedures.  The pretty stuff in HTML, Javascript, CSS and PHP.

Why not go whole hog and store all of it in the database?  Have a single
script in front that does the C in MVC and tells the DB what content to
extract.