Consuming one sp into another SP
We have a web application which uses Stored Procedures.
Now we are working on a mobile app which is a shorter version of the Web application we already have.
There are many screens which do not have all fields as compared to its web version, so to make the request size smaller we only trying to fetch the column which we require for the screen.
We have two options
1. Write a new sp which will return fewer fields from the table.
2. Somehow consume the existing SP in another SP and return only selected fields from it.
The first approach will cause a duplicate of SP login in many cases
The Second option is even possible not sure.
Could any share what would be the best approch for us here.
Now we are working on a mobile app which is a shorter version of the Web application we already have.
There are many screens which do not have all fields as compared to its web version, so to make the request size smaller we only trying to fetch the column which we require for the screen.
We have two options
1. Write a new sp which will return fewer fields from the table.
2. Somehow consume the existing SP in another SP and return only selected fields from it.
The first approach will cause a duplicate of SP login in many cases
The Second option is even possible not sure.
Could any share what would be the best approch for us here.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I think, more than the payload size, the logic used to obtain multiple columns across tables would cause your SP to slow down for mobile use. If that is not the case and you are concerned only about payload size, then you might want to experiment and check if there is a large impact due to this change. I would believe, it may not be. If you are having a different controller, you can trim the response before sending it to the mobile front end.
This would only be only the case, if the structure of the queries would be different. Just using viewer columns does not change the structure.
Or from the perspective of the query optimizer: When in this case a significantly better place would be possible, then there exists already a structural problem in the database.
Or from the perspective of the query optimizer: When in this case a significantly better place would be possible, then there exists already a structural problem in the database.
Do you have already some sort of caching implemented? Cause using a different DAL should then not gain that much performance.
If not, then using fewer columns in the SQL Server output may increase through-put to your application server. But as they should be local and the query plans should not differ drastically, I would only expect minimal improvements (non-significant).