By mswatcher
via davybrion.com
Published: Nov 24 2008 / 14:54
In case you don’t know what is so bad about this, think about this: if you have 5 employees you first send one select statement to the database to get their id values. Then you send another 5 select statements to the database to get the data of each employee. Oh well, 6 queries isn’t that big of a deal right? It sure as hell is if you could’ve just as easily gotten all of the required data with one query (and only one expensive roundtrip)! Imagine you have to calculate the paychecks of 100 employees instead of 5. How about 1000 employees?
-
Keyboard Navigation for Input Fields using JQuery
-
Using UI components in jQuery Mobile
-
Work or Whine. A Rant.
-
Model2Roo: a Model Driven Approach for Web Application Development based on the Eclipse Modeling Framework and Spring Roo
-
Save Camera Captures in Media Library for Windows Phone
-
Adobe confirms: no Flash for Chrome on Android
Comments
willcode4beer replied ago:
If the word database wasn't in there, no one would complain about the code itself.
This is what happens when you create an API that rewards the wrong practice. Unfortunately, these types of APIs are all too common.
Instead of criticizing the code, the criticism should be leveled on the design of the API that made that code so easy to write. When designing an API, you should be exceptionally careful. Make the "right" thing easy to do. Document the best ways to do things well. Make the "wrong" thing difficult to do. That's 80% of the battle in preventing this type of behavior.
sproketboy replied ago:
This is a fundamental problem of ORM. Too much abstraction hides the amount of processing going on here. The author complains about getting each employee one-by-one by id - but also I would say that calling a PayDay method on each one - creating a new Paycheck object - is also bad. Heck, the method is not even returning the modified employee objects.
This could have been wrapped up in 1 SQL statement with little scalability issues.
Voters For This Link (16)
Voters Against This Link (0)