Home/ Questions/Q 3664556
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-19T01:39:36+00:00

There is ‘team_sector’ table with following fields: Id, team_id, sect_id, size, level It contains

  • 0

There is ‘team_sector’ table with following fields: Id, team_id, sect_id, size, level

It contains few records for each ‘team’ entity (referenced with ‘team_id’ field). Each record represent sector of team’s stadium (totally 8 sectors).

Now it is necessary to implement few searches:

  • by overall stadium size (SUM(size));
  • the best quality (SUM(level)/COUNT(*)).

I could create query something like this:

SELECT TS.team_id, SUM(TS.size) as OverallSize, SUM(TS.Level)/COUNT(TS.Id) AS QualityLevel
FROM team_sector
GROUP BY team_id
ORDER BY OverallSize DESC / ORDER BY QualityLevel DESC

But my concern here is that calculation for each team will be done each time on query performed. It is not too big overhead (at least now), but I would like to avoid performance issues later.

I see 2 options here.

The 1st one is to create 2 additional fields in ‘team’ table (for example) and store there OverallSize and QualityLevel fields. If information if ‘sector’ table is changed – update those table too (probably would be good to do that with triggers, as sector table doesn’t change too often).

The 2nd option is to create a view that will provide required data.

The 2nd option seems much easier for me, but I don’t have a lot of experience/knowledge of work with views.

Q1: What is the best option from your perspective here and why? Probably you could suggest other options?

Q2: Can I create view in such way that it will do calculations rarely (at least once per day)? If yes – how?

Q3: Is it reasonable to use triggers for such purpose (1st option).

P.S. MySql 5.1 is used, overall number of teams is around 1-2 thousand, overall number of records in sector table – overall 6-8 thousand. I understand, those numbers are pretty small, but I would like to implement the best practice here.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    A few (ten)thousand records are nothing you should be worried about.

    Best practices are

    • store data in a normalized fashion and let the database engine handle calculations
    • index your data properly, do an index maintenance now and then
    • avoid storing aggregated values with “parent” records
    • do some result caching in the application layer to avoid hitting the DB server more often than necessary
    • deal with performance issues when you get them

    Yes, the database will calculate the SUM() whenever the view/query is executed, but I would expect results to be pretty instant for the scenario you describe.

    If you encounter a really complicated view that takes a long time to calculate and and you cannot find any way to optimize your tables any further, you can introduce a helper table that is filled with the view results regularly (or via triggers) and and query that table instead of the slow view.

    IMHO, anticipating possible performance bottlenecks and “closing” them before they actually show up is wasting your time.

    • 0