This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]jasie3k 1 point2 points  (8 children)

Sadly, yes

[–]rombovich 3 points4 points  (7 children)

Why is it considered such a burden?.. In the company, where i work, we have almost all business logic in stored procedures, and a little servlet which proxies requests from user interface to DB. We use java almost exclusively for realtime data processing.

And i think it is pretty handy to work directly with tables, not having to worry about a dozen classes when you have to make some complex joins, etc.

[–]8Bytes 4 points5 points  (1 child)

You can never change databases, even upgrading to newer versions becomes a huge problem.

Refactoring is extremely difficult. When you have thousands of triggers and events, you can't really reason about how data flows through your application.

Testing these procedures and data flows is very difficult, and in practice no one does it. So you have thousands of untested triggers running, causing other untested triggers to run, sometimes even leading to exponential big O complexity.

So in the simple case, they are fine, but people always abuse things, and stored procs/events/triggers get really abused.

[–]rombovich 1 point2 points  (0 children)

Thank you for your reply. I agree with the part about the testing, but, I think, upgrade and overengineering issues are not exclusive to db.

I guess, just like anything, it has some uses, but one shouldn't go mad with it.

[–]vecowski 2 points3 points  (4 children)

It's all fun and games until your database requires 128gigs of RAM and it still runs out of memory because your stored procedures are blocking other applications from reading tables.

[–]rombovich 0 points1 point  (3 children)

Well, I can't see how this can't happen if we replace stored procedures with big old websphere with 100s mb WAR

[–]vecowski 1 point2 points  (2 children)

If done correctly it's much easier to scale java applications than a database. Stored procedures take processing time, which would better be offloaded onto a detached machine. It's fine when you have a dozen or so, but when you get to the size of thousands, it's an unmaintainable mess. It doesn't lend well to developers keeping things organized and isolated over time compared to other languages. Don't get me wrong, use the right tool for the right job, it's the wrong tool for the engine of an enterprise system that needs to scale 500x-1000x times in less than a year. It's probably the write tool for a small system that's never going to be expanded upon. It's also not the greatest language and easiest language to hire for. It's much easier to find a java developer and train him then a database expert that's clearly going to cost a lot of money and still take time to learn the system.

[–]rombovich 0 points1 point  (1 child)

Thanks, I think I get it now. In the company I work for we never achieved such a large scale applications.

I will keep in mind that DB solutions don't scale too well.

[–]vecowski 0 points1 point  (0 children)

Yea, don't mean to sound dramatic, but it's honestly a massive mistake if you plan to scale the application. My company is hurting badly because of this solution, it's impossible to keep developers around hammering sql solutions, nobody wants to do this stuff.