1๐
How about one generic computation table?
computation_id | key | value
-----------------------+---------------------------+---------
monthly_average | "reading_point_id+month" | 1.2
weekly_maximum | "reading_point_id+week" | 9
monthly_global_maximum | "month" | 12
The key format would be defined along side the user defined computation.
The computation_id and identifier would be your compound primary key.
The computation_id could be a numeric field (that would give you faster index lookups).
I suspect performance would be quite good, despite the one large table.
I hope iโm not misunderstanding your requirements.
0๐
Have you considered using a simple Key-Value cache system like Redis or Memcached? You can store all the values on fly in values in the cache. If you ever need to recalculate, you can rebuild the cache. But otherwise, if all you want are values and fast lookup, a cache would work well. Without knowing what your queries will look like, it may be too premature to suggest any optimization for database tables.
If caching is too early for you, you can also write your own ModelManager methods to dynamically compute and store the values.
class WaterMeterManager(models.Manager):
def pre_calculate(self):
return self.get_query_set().aggregate(Avg('value'), Max('value'), Min('value'), Sum('value'))
class WaterMeter(models.Model):
objects = WaterMeterManager()
You can use this as:
WaterMeter.objects.pre_calculate().get('value__min')
- [Answer]-User matching query does not exist โ django
- [Answer]-Python social auth 404 error
- [Answer]-Multiple joins in Django model
- [Answer]-Ajax to notify about variable change on server
- [Answer]-Cannot import python social auth into Django app that uses custom login