Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
> 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 | |
We also thank MIT for the use of their facilities. |