A query per request or a query only for N requests?

Asked

Viewed 59 times

0

I honestly do not know if I am asking a very obvious question, that face we look and talk like this: Obviously the dynamic query by request is better!

But come on...

The application

We are talking about a web application in ASPNET.MVC 4.0, of indicators - a Dashboard style. The application size I would say is small/medium, with Oracle database.

Setting

I need to do N querys to display the indicators. However, the filters can be done in memory or directly in the database. The point is, as we are talking about indicators, I have mathematical operations involved. I mean, I need a result like:

ID         Valor         Tipo

1          25560.00      1
2          2330.00       1
3          140.00        2
4          10.00         1
5          50.00         3
6          40.00         3
7          33.00         1

At the end of the day.... my requisition would be something like:

  1. Show me a percentage of all Ids that have Type = 1
  2. Show me a percentage of all Ids that have Type = 2
  3. Show me a percentage of all Ids that have Type = 3

Question

What’s best?

  1. Make a request only bringing all the IDS with all the Types, placing all the data inside the Viewbag, do the mathematical operations via JS and also filter the Type via JS?
  2. Do all bank operations, view consolidated information in the application and go to the bank as often as requested?
terminology methodology
  • 1

    I guess with the information you’re giving, you can’t answer. It is not clear what the mathematical operations would be nor why you would need multiple queries. Looking at the example, a single query with aggregation (GROUP BY...) it seems that it would solve, in the bank, easily.

  • I have a formula to display what I want.... The point is: do all the operation in the bank for each request or simply bring everything in viewbag and handle everything via JS?

  • 1

    There is no precise answer to this, it depends on the case! In general it is preferable to do in the bank, but it is also not desirable to make many requests.

  • The problem is it’s kind of old-school stuff, you know? At a time when data processing and memory usage was very expensive... there is no thought or theory for the "present day"?

  • I also think there is no correct answer. Each case is a case. What is the goal to be achieved? Higher speed, greater readability, greater ease of development, greater scalability, greater interactivity, lower traffic, lower server stress, shorter development time, etc.

  • The goal is: faster filtering time and lower cost for the bank.

Show 1 more comment
No answers

Browser other questions tagged terminology methodology

You are not signed in. Login or sign up in order to post.