Home/ Questions/Q 6127965
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T16:34:22+00:00

due to performance reasons we refactored some quick ‘n’ dirty implementation of our data

  • 0

due to performance reasons we refactored some quick ‘n’ dirty implementation of our data access (sql).
As before we accessed our objects step by step. First the basic data, than filling that up, with some related data, which might be filled up itself with some other relating data.

As of now all data is accessed in single sql statements, which are more complex, but not too much – with four joins tops.

As a consequence, the data we retrieve isn’t in a object like format (actually nested arrays), like

prop1
prop2 -> prop2a,
         prop2b -> prop2b1
                   prop2b2
prop3 -> prop3a
         prop3b

and instead the data is all “flat”, like

prop1
prop2a
prop2b1
prop2b2
prop3a
prop3b

My oo-instincts tell me to preprocess this data after retrieval and send it to the frontend (html, js – which is our only client) in the object-like structure as it has been send before the refactoring. On the other hand, performance reasons implie to only process as much as really needed and if possible let the client do some worklifting.

Bottomline: What’s generally speaking the best / a good practice here?

a) process data preparation in the backend

b) send the data as retrieved to the frontend and process it there

c) switch to a ORM architecture as quick as possible

Big Thanks,

Robson

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Given all of the apps I have worked with for over 20 years, performance is always king. You should always let the RDBMS do its job by using joins and whatever you need to do in the backend to retrieve only the data you need (note: you may need to look at “explain plan” or equivalent or add indexes on tables to get the best performance).

    Regardless, only retrieve the data you need. By retrieving more data you then add more data “over the wire” and then have to process and remove data on the front end.

    As for ORM – it’s a model that is often followed and I too believe strongly in using an ORM tool, but don’t create objects just for the sake of creating objects. If I can return 100 rows of data of exactly what I need vs. returning 100 related objects I would much rather (for performance reasons) return the former.

    My vote is a). I always like to do as much work on the backend since you may in the future have different types of clients.

    • 0