November 11, 2014 at 8:07 pm
Comments posted to this topic are about the item Double Up During Trips
November 12, 2014 at 1:19 am
Combine Insert and Select into one call?? But of course - all the time. It's nothing new.
We've been doing that in ASP.NET ever since 2005 when we started working with Visual Studio 2005 and using the strongly typed datasets. All Insert and Update procedures return a dataset of the updated/inserted rows, it's built in - create a new table adapter in a dataset and the wizard kicks in, select Create New Stored Procedures, pick Advanced Options on the next screen and you can select whether or not to refresh the data table, which adds the select statement into the stored procedure after the insert or update. We always do.
Once the procedures have been created I go in and manually refine and tune them, adding error handling and often changing the select query to return fully looked up (denormalised) data. You just have to ensure you have the same select query in all the various select/insert/update stored procs for that table adapter.
November 12, 2014 at 2:24 am
Of course, this can be absolutely pointless and a waste of resources if the call is made asynchronously or is a one way call. It also places a large assumption of how and why something is being called which is against best development practices.
As usual, it depends.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 12, 2014 at 2:33 am
In general no, I would feel this to be inelegant and create less re-usable code.
In the example above where someone is inserting data and then displaying it, presumably a retrieval / display routine needs to be developed which I will prefer to use post-insert where necessary - the hit on a single extra trip can be swallowed. I'll be honest, I never liked typed datasets much though.
Is the concept feasible in EF anyhow (obviously without just issuing SQL)? It does take a slight difference in approach to be trip efficient in EF, and we spend no insignificant effort ensuring that we do that. Inserts and updates in particular require a variety of approaches in my experience to be effective.
November 12, 2014 at 3:00 am
call.copse (11/12/2014)
I...I never liked typed datasets much though...
I liked them originally, however, I much prefer immutable business objects. It is amazing how many poor practices cannot be done when working with immutable objects. Suddenly side effects are blatantly obvious and obviously wrong when you see them. It is easier to pick up code to maintain as you can see exactly when there is a change to objects. Ironically, typed datasets are too loose.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 12, 2014 at 3:37 am
This approach doesn't lend itself to being sargable. The statements should be separate and not force the sql server or application to betray the intended design.
November 12, 2014 at 6:22 am
I realize that many managers are loathe to invest in developers' knowledge when those developers might leave your company for another position, but imagine that a manager elsewhere is investing in his developer.
Managers investing in developers??!?? LOL (That's a good one...)
I'm convinced that Steve lives in an entirely different world from myself. 98% of my professional education, knowledge and skills were developed by me, on my dime, and almost always on my time. (Sans any Google and MSDN foo required to beat software into submission...) I received more appropriate training when I was in the military than in the civilian world. And more in the electronics/wireless/semiconductor sector than software or admin.
November 12, 2014 at 6:43 am
I come from the Developer side of the house, (12 years of it in several flavors) and one of my biggest growing experiences as a developer was with this vibrant DBA, who would challenge me to make my calls as efficient as possible. We started this competition by his writing stored procedures against his relational database to compete with my hierarchical database extractions, and we would compare notes. Eventually, what impacted me most was his ability to take my "incredibly Coool function code" and make it faster and more responsive by teaching me how SQL Server responded to my call. Now as a DBA, I love the wisdom he handed me through those challenges. I understand more now than I did then, 😛 but now know how little I really know in comparison to what goes on.
My favorite story of efficiency was the the old AppleWriter that worked in 16k memory (kilobytes for you youngin's ;-)) and could still handle documents that were a megabyte or more in size. It was a very different mentality then, and there is wisdom to learn from it.
November 12, 2014 at 6:51 am
My favorite story of efficiency was the the old AppleWriter that worked in 16k memory (kilobytes for you youngin's ) and could still handle documents that were a megabyte or more in size. It was a very different mentality then, and there is wisdom to learn from it.
The gentleman that authored AppleWriter made a mint, retired and still codes, but gives it away. Don't lose yourself in his wonderful web site.
November 12, 2014 at 7:25 am
The gentleman that authored AppleWriter made a mint, retired and still codes, but gives it away. Don't lose yourself in his wonderful web site.
http://arachnoid.com/%5B/quote%5D
OH great, there goes my focus.. :-p That site does have varied and interesting ideas, and I then "HAVE" to go find out more. Curiosity is such a dangerous drug; I get "such wholesome returns on conjecture out of such trifling investments of fact." (Mark Twain)
November 12, 2014 at 8:17 am
ahakes (11/12/2014)
...I then "HAVE" to go find out more...
I started to myself but stopped myself just in time. It was a close call!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 12, 2014 at 8:30 am
Of course batching up SQL operations is generally more efficient than processing them synchonously one at a time, especially if we're talking about inserts. For example a developer may build an ETL processes that parses XML or EDI files, cursoring one record at a time in a .NET or Java application, and inserting one record at a time into the database table. Then they have the audacity to say that the database is the bottleneck. In fact both .NET and SQL Server are highly efficient tools; it's the developer's own ignorance of software and database architecture that's the real bottleneck. That's what happens when developers see things only in abstract terms of objects, properties, and methods rather than nodes, network packets, and transactions.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 12, 2014 at 9:42 am
Eric M Russell (11/12/2014)
...a developer may build an ETL process...
We all know that a developer who did that using 3GLs is using the wrong tools (i.e. I am not correcting Eric). Having said that, it does happen though!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 12, 2014 at 9:58 am
chrisn-585491 (11/12/2014)
Managers investing in developers??!?? LOL (That's a good one...)
I'm convinced that Steve lives in an entirely different world from myself. 98% of my professional education, knowledge and skills were developed by me, on my dime, and almost always on my time. (Sans any Google and MSDN foo required to beat software into submission...) I received more appropriate training when I was in the military than in the civilian world. And more in the electronics/wireless/semiconductor sector than software or admin.
Mine too. It's been rare that I've had people invest in me, but it has happened.
Trying to move the needle here, get managers to rethink thew orld.
I will also say that when I invest in myself, I'm looking for some payback and am then often looking for a new job. When I've had companies invest in me, I'm more than willing to stay and pay things back to them.
November 12, 2014 at 10:04 am
chrisn-585491 (11/12/2014)
My favorite story of efficiency was the the old AppleWriter that worked in 16k memory (kilobytes for you youngin's ) and could still handle documents that were a megabyte or more in size. It was a very different mentality then, and there is wisdom to learn from it.
The gentleman that authored AppleWriter made a mint, retired and still codes, but gives it away. Don't lose yourself in his wonderful web site.
http://arachnoid.com/%5B/quote%5D
Very cool
Viewing 15 posts - 1 through 15 (of 27 total)
You must be logged in to reply to this topic. Login to reply