November 12, 2014 at 10:16 am
We've seen all before. That legendary appplication that was conceived, coded and put into production within two weeks. The developer gets a pat on the back and the project is held up as an example for all. It then gets handed off to another developer, where it stays in perpetual maintenance mode for the next two years while the original developer goes on to spearhead several other similar efforts.
Of course the best way to have your SQL operations executed within the same batch is to contain them within a stored procedure, perhaps with a multi-values input parameter if needed. It doesn't fit into the entity framework model quite as tightly, but it's possible and it works long term.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 12, 2014 at 10:34 am
When I first saw the title "Double Up During Trips", I thought it was going to be a post about how to save money by doubling up on the hotel room and cab. I know that Steve spends a lot of time traveling out of town. 🙂
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 12, 2014 at 10:52 am
I thought it was going to be an editorial of getting two tasks done on one trip e.g. Steve to a UK conference and visiting his UK colleagues at the same time. Somehow I get the feeling that not many people assumed server round trips was the order of the day!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 12, 2014 at 11:44 am
Eric M Russell (11/12/2014)
When I first saw the title "Double Up During Trips", I thought it was going to be a post about how to save money by doubling up on the hotel room and cab. I know that Steve spends a lot of time traveling out of town. 🙂
Same thought here. The title reminded me of something my former pastor once said, that he never travels alone.
Tony
------------------------------------
Are you suggesting coconuts migrate?
November 12, 2014 at 1:12 pm
Well, there is something to be said about reducing round-trips, but that is not exactly what this author is talking about. His statement of
one of the simplest things you can do to speed up your application is to reduce the number of trips you make to your database, even if you don't make any changes to the amount of data you update or retrieve.
is a bit too broad. He is really talking about focusing on reducing the number of connections in general, not any sense of improving the process, which probably would include some reduction in the amount of data going back and forth. As others have (I believe) mentioned here, if you are going to issue a batch of statements, why not just encapsulate them in a Stored Procedure? And connection pooling already helps reducing the overhead of establishing new connections each time.
Of course, this is not to say that there aren't times when it is entirely appropriate (for the operation at hand) to do some DML and then return data. And in some cases it can even be a single statement if using the OUTPUT clause.
This seems like a case of a little bit of knowledge, especially outside of its proper context, can be a dangerous thing ;-). The more I answer questions on StackOverflow and DBA.StackExchange, the more I see people who, if only judging by Reputation Points, should be fairly intelligent/experienced/skilled folks giving good advice, but who are actually handing out rather horrible advice (at least in terms of this wacky database stuff).
Interestingly enough, this topic of "reducing round trips" has come up twice in the past 4 days, at least in terms of what I have seen and answered (I suppose it could have come up more and I haven't seen those questions). In one case someone wanted to accomplish multiple SELECTs, all based on the same ID value, in a single call. It is rather easy to do and is all logically related data, though I did advise that it would not likely produce any noticeable performance gains. The other case was someone trying to SELECT some data that he both wanted to INSERT into a table for later use but needed that data sent back to the app for immediate use. That case, at least, has the right intention of reducing otherwise wasteful back-and-forth since the alternative is to SELECT the data and then just send it right back, unaltered. The only real complication was that he is using Entity Framework and it doesn't support either the INSERT...SELECT construct or the OUTPUT clause, so it has to be custom SQL.
SQL# — https://SQLsharp.com/ ( SQLCLR library ofover 340 Functions and Procedures)
Sql Quantum Lift — https://SqlQuantumLift.com/ ( company )
Sql Quantum Leap — https://SqlQuantumLeap.com/ ( blog )
Info sites — Collations • Module Signing • SQLCLR
November 12, 2014 at 4:18 pm
Eric M Russell (11/12/2014)
When I first saw the title "Double Up During Trips", I thought it was going to be a post about how to save money by doubling up on the hotel room and cab. I know that Steve spends a lot of time traveling out of town. 🙂
Ha! no doubling up in my room unless my wife is with me
November 12, 2014 at 5:54 pm
Steve Jones - SSC Editor (11/12/2014)
Eric M Russell (11/12/2014)
When I first saw the title "Double Up During Trips", I thought it was going to be a post about how to save money by doubling up on the hotel room and cab. I know that Steve spends a lot of time traveling out of town. 🙂Ha! no doubling up in my room unless my wife is with me
BWAAHHHH-HAAAAA!!!! You REALLY need to reword that! 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
November 13, 2014 at 8:48 am
Jeff Moden (11/12/2014)
Steve Jones - SSC Editor (11/12/2014)
Eric M Russell (11/12/2014)
When I first saw the title "Double Up During Trips", I thought it was going to be a post about how to save money by doubling up on the hotel room and cab. I know that Steve spends a lot of time traveling out of town. 🙂Ha! no doubling up in my room unless my wife is with me
BWAAHHHH-HAAAAA!!!! You REALLY need to reword that! 😉
He really shouldn't...some people will have had a bad day and they deserve a good chuckle.
Steve, just keep your doubling up to yourself. What happens in private between consenting adults is between them alone. Unless they are foolish enough to record it :ermm:
(I am assuming that Mrs Jones has a good sense of humour too. Seems a fair assumption.)
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 13, 2014 at 10:19 am
As many of you know, I have been at this for a while. So from my back pages comes this.
Early on, we watched every byte of the program executable and managed the executables at the register level. If one section of the program was too long, we would allocate a new pseudo-register and code in the new section. In addition, we really did manage down to how a binary bit field would be declared and how to and or or against the bits.
Later when COBOL and that generation of languages came to be, we argued how to use the search and searchall subroutines, self-defining datatypes, and using the built-in sorting or writing your own bubble sort. There were intense arguments as to what was faster and cleaner.
In the next generation of code, we were told not to worry about the efficiency of the code. The folks who paid us understood that developer costs were the most costly so who cared how you wrote it just get it done and if it was slow hardware was cheap compared to developer time so they just bought more memory, disk, etc. That lasted a while and then it started to catch up to them and the cost for hardware was very high.
Soon the efficiency in the backend became an issue and the RDBMs became king. With indices, being managed internal to efficient firmware and the ability to multiprocess on the backend the industry was able to regain some of the lost efficiency.
However, the need for IT processing has exponentially increased over time, and it continues to grow more rapidly them we imagine. With data growing exponentially and the need or desire for that data increasing almost as fast as the mass of data increases we find that efficiencies need to be captured anywhere we can find them.
I really do like the idea of reuse as mentioned earlier. However, elegant code and reuse is only useful to the developer. There are times is will be sacrificed for the needs of throughput the user demands. This is the tradeoff. We can be elegant if it is efficient. Elegance matters some time only to the developer. Speed and efficiency matters at all times to the user.
Therefore, the pendulum has swung again to the efficiencies, and we are again to understand that this is an art, and a science but we need to be quick about it.
Not all gray hairs are Dinosaurs!
November 14, 2014 at 8:22 am
For once I have to disagree with Miles.
Efficiency of coding and delivery of business needs go hand in hand.
Coding efficiency, for me, is maintainable code that this relatively performant.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 14, 2014 at 9:53 am
Gary Varga (11/14/2014)
For once I have to disagree with Miles.Efficiency of coding and delivery of business needs go hand in hand.
Coding efficiency, for me, is maintainable code that this relatively performant.
Gaz, disagreement is healthy and causes one to think and also rethink. Thank you for saying this. I appreciate the honesty.
However, consider the old question, please. Does the group paying for your product want the product/service fast and cheap? If so, in many or even most cases the product/service cannot be good, or a minimum reach the level of excellence we would normally achieve. When we compromise cost and deliver within a tight schedule, the quality drops.
Thus there are times we do the best we can within the limits of the project. When faced with time and cost constraints, we have to decide where to compromise. Some decide that they will not take on such work because they refuse to make a compromise in efficiency, reuse, and professionalism. To a point I agree, a job poorly done is worse then no job.
But we must face the bottom line. Would you rather compromise the efficiency of your code, or feed your children?
M.
Not all gray hairs are Dinosaurs!
November 14, 2014 at 10:07 am
Miles Neale (11/14/2014)
Gary Varga (11/14/2014)
For once I have to disagree with Miles.Efficiency of coding and delivery of business needs go hand in hand.
Coding efficiency, for me, is maintainable code that this relatively performant.
Gaz, disagreement is healthy and causes one to think and also rethink. Thank you for saying this. I appreciate the honesty.
However, consider the old question, please. Does the group paying for your product want the product/service fast and cheap? If so, in many or even most cases the product/service cannot be good, or a minimum reach the level of excellence we would normally achieve. When we compromise cost and deliver within a tight schedule, the quality drops.
Thus there are times we do the best we can within the limits of the project. When faced with time and cost constraints, we have to decide where to compromise. Some decide that they will not take on such work because they refuse to make a compromise in efficiency, reuse, and professionalism. To a point I agree, a job poorly done is worse then no job.
But we must face the bottom line. Would you rather compromise the efficiency of your code, or feed your children?
M.
In my experience, the business is usally more forgiving when it comes to time and cost than they are willing to forgive a non-viable deliverable. Writing efficient code and feeding my children go hand and hand. My reputation as a solution builder is my job security and mens of income. My punctuality, political finesse, and charming personality are insufficient to keep me afloat.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 14, 2014 at 10:23 am
Eric M Russell (11/14/2014)
In my experience, the business is usally more forgiving when it comes to time and cost than they are willing to forgive a non-viable deliverable. Writing efficient code and feeding my children go hand and hand. My reputation as a solution builder is my job security and mens of income. My punctuality, political finesse, and charming personality are insufficient to keep me afloat.
Eric,
Glad to hear that and for the most part I do agree. The issue I speak of is one you actually alluded to. You say and correctly the business is usally more forgiving when it comes to time and cost than they are willing to forgive a non-viable deliverable. This is in fact usually the way it is. But what do we do in the unusual times when business is not forgiving? We either do not do it, or we deliver a viable solution that is not the most efficient, or part of the solution, walk away or ...
And I am certain your punctuality, political finesse, and charming personality are sufficient to get you a long ways down the road.:-) But again you are correct, they are insufficient to keep one afloat.
M.
Not all gray hairs are Dinosaurs!
Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply