5 ms·
That's the first thing I thought. Having spent literally the last 10 years removing stored procedures and extensions from software products to eek out a little
by kryten 13y ago
That's the first thing I thought.
Having spent literally the last 10 years removing stored procedures and extensions from software products to eek out a little more from the black box that is a database engine and remove all the rats nest of logic, why would I want to go and do the same all over again?
Of all the things I've learned in the last 20 years or so, you shouldn't stick any logic or programmability inside the database engine. It's hell down the line.
And don't get me started on where the programmability abstraction gets fudged in with the data resulting in executable data and all sorts of security hell.
- kijin 13y agoIn a key-value store like Redis, it's actually quite useful to be able to generate an atomic query that says something like "If List A contains B, return C. Otherwise check whether List D contains E, and if so, return all the keys and values of Dictionary F, but otherwise return zero." But of course, Redis already has Lua scripting which is a nearly perfect fit for its use case. JavaScript looks terribly cluttered by comparison. Some sort of V8 integration might make sense if the goal is to make Redis even easier to use with node.js, but I don't see anything in the documentation to suggest that this is what's happening.
- kryten 13y agoCouldn't this be handled with some conditional primitives like in ARM assembly adequately? Actually that's not a bad idea ... writes it down...
- andrewflnr 13y agoExactly what bad things happen when you put logic in the database? At my current employer, most business logic is in stored procedures.
- kryten 13y agoLots. Here you go: 1. CPU time goes up. When you need to scale up, your brick wall is a lot closer. 2. When you do need to scale up, moving it out of the database engine is very expensive and time consuming. 3. The languages are archaic, obtuse and inadequate for representing business logic and don't cover ALL concerns. How do you call a web service and do an update in a transaction for example? How do you send an email? 4. It's incredibly difficult to test as the entire thing is stateful. 5. Error handling and reporting is terrible. 6. You lose database portability. This is a big issue these days, particularly when you get whacked with major licensing model changes. 7. Versioning and deployment with the application is utterly painful. Etc etc...
- Shorel 13y agoI don't think most of these apply to JavaScript nowadays.
- andrewflnr 13y agoPersonally, I'm interested in the general answer.
- andrewflnr 13y agoHaha, well, we're running a small site on a huge server and we're not that into automated testing. We actually send email by inserting into a table that serves as a queue. SQL server already costs a fortune. Honestly, though, I've felt a lot of that already, but didn't really attribute it to stored procedures. Can you explain why stored procedures are faster than code in my app? It seems like they're both run in a fairly optimized VM, but I don't know much about the details. We're using C# at work, but if I was using something like Python I would be more tempted to move things into the db for performance reasons.
- kryten 13y agoIt depends entirely on round trips to the server and your use cases. Generally speaking though, if you keep your result set as narrow as possible, post process aggregates in code, keep your join count low and keep you round trips per request low then c# will destroy stored procedures.
- ironchef 13y agoThe usual culprits are scaling and versioning / config mgmt; however, anything can be misused (and there's no one size fits all). I've seen it done well once. Once.
- kryten 13y agoThat's one more time than me :)
- twistedpair 13y agoSo many times I've seen people picking up the pieces of a "We'll just do everything in SP's!" project architecture." Anti-pattern city. The typical answer to make it scale or maintain well is to just throw it out.
- dagw 13y agoHonest question. Where should you stick your db related logic if you don't want to replicate it in every app that touches the database. Do you write some sort of middleware that sits between the apps and the database and never let any apps talk directly to the database?
- kryten 13y agoExactly that. The "middleware" as you put it can manifest itself as one of several things (vastly simplified explanations): 1. Sits in front of your data store and exposes your application's API via HTTP for example. Typical SOA/public API type architecture. 2. Sits inside your web application as a component which you talk to via your internal API. In a Ruby/Python/PHP/Java/C# setting, you would typically have a class with methods on it which correspond to API calls. 3. Ships with your application (if a desktop one for example) and serves an internal API. As above but the component ships with the desktop application. We do 1 and 2 in our product using the same shared components (domain models). In actual fact, it's completely hiding behind NHibernate so we don't actually ever consider the database as part of the problem that needs solving. It's purely where we put our stuff when we don't want it in memory.