Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 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.  I personally like the separation from the front end.

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

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

- Eric C







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org