Timeline for CRUD without an ORM
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 4, 2016 at 18:30 | comment | added | Andy | The downvote was by me, because I don't like your suggestion. I wouldn't want to hear that suggestion in my company. I believe stored procedures are a thing of the past and should not be used until absolutely necessary. Among other things like caching we started adapting SOAP/REST web services so we could transform the stored procedures from SQL into a more common, and to a common programmer, easier-to-understand code (Java, C#, PHP, JavaScript). | |
| Sep 4, 2016 at 18:26 | comment | added | Andy | @Brandon You are an experienced developer, that's why you're fine with that. I would most likely be too. But take a mediocre programmer, put them in front of a, let's say, C# project containing most of business logic inside bugged SQL stored procedures and they are going to be lost for quite some time. Should the bugs be within the C# code itself they would be able to find a solution much quicker, because they are a C# developer after all, not an SQL enginner. From my experience moving procedures to code has proved to be cheaper when searching for new developers, which clients appreciate. | |
| Sep 4, 2016 at 17:57 | comment | added | Brandon | Somebody care to explain the down vote? I gave the OP a suggestion based on real-world experience and they were happy with it. What do you suggest would have made this answer better? | |
| Sep 4, 2016 at 17:54 | comment | added | Brandon | @mgw854 My thoughts exactly. I work on SaaS apps where performance and scalability are important and have always either had SQL expertise or had experts around who know SQL very well. My team evaluated ORM a few months ago for a new project and the outcome was that it might (questionably) save us a few hours up-front, then cause us to spend lots of time debugging. Or we could spend a few hours longer hand-writing SQL, and spend very little time debugging. It comes down to time-to-market, how important performance is, and what skills the individual developers on a team have. | |
| Sep 4, 2016 at 17:51 | comment | added | Brandon | @DavidPacker I have never had a problem debugging stored procedures. But I have had problems debugging SQL code which is generated dynamically. I don't care to debate ORM vs. non-ORM (been there - found everybody generally has their mind made up, either way), but I feel I need to respond because your comment is very subjective in my opinion. | |
| Sep 4, 2016 at 14:24 | comment | added | Greg Burghardt |
The select N+1 problem is a common one with ORM's, however this can be mitigated by configuring it properly to do a join when fetching relationships. I think time wise they are the same, however you have two sets of code in two languages to maintain. I think to just go ORM and nothing else, or just go stored procedures ignores the strengths of both tech stacks. A combination, leaning towards ORM I've found to be more useful.
|
|
| Sep 4, 2016 at 13:18 | vote | accept | user974407 | ||
| Sep 4, 2016 at 12:32 | comment | added | Andy | Stored procedures, yuck. Good luck debugging those. | |
| Sep 4, 2016 at 7:46 | comment | added | Laiv | What about MyBatis? It works just with the sql statements you define for each operation (insert, delete, update, select) and it also does object mapping. It supports procedures aswell. | |
| Sep 4, 2016 at 5:46 | comment | added | mgw854 | This is the way to go... stored procedures are more powerful than any ORM I've ever come across. Wearing them in a DAO keeps everything loosely coupled and allows for mocking and unit testing. If I need to do anything but simple CRUD work, I'd rather write SQL than let the ORM generate something that would never pass a code review. It may be an unpopular opinion, but with the scale of data that I work with, even a few bad queries are unacceptable. | |
| Sep 4, 2016 at 4:26 | history | answered | Brandon | CC BY-SA 3.0 |