Currently, we're doing the "join" in python code, which is an n^2 operation. If the amount of event names stays relatively low, that might be OK, but it's not ideal.
I started down this path for flexibility reasons: being able to define arbitrary criteria for naming events sounds cool. But figuring out which name(s) map to an event becomes harder. Definitely harder to do in SQL.
Maybe something like having a foreign key on EventName.id = Event.event_target+Event.event_type would be a suitable workaround (though it only clearly supports two filters). Then we could layer more criteria on top of it for more advanced views (in a separate table).
Seems messy.
Currently, we're doing the "join" in python code, which is an n^2 operation. If the amount of event names stays relatively low, that might be OK, but it's not ideal.
I started down this path for flexibility reasons: being able to define arbitrary criteria for naming events sounds cool. But figuring out which name(s) map to an event becomes harder. Definitely harder to do in SQL.
Maybe something like having a foreign key on
EventName.id = Event.event_target+Event.event_typewould be a suitable workaround (though it only clearly supports two filters). Then we could layer more criteria on top of it for more advanced views (in a separate table).Seems messy.