Structure with "data" is suboptimal for alignment with rails standards

[MartinHinz]

We should get rid of the unifying data model, and instead reflect the diversity of our data sources better by using the separate data models directly, joining them in the views or using a abstract class like construction?

[joeroe]

I've been experimenting with this in https://github.com/xronos-ch/xronos.rails/tree/databrowser. Removing Data.everything and instead filtering does make things more idiomatic. It also has the benefit of allowing us to re-use existing filter logic on the individual models, be more precise in the count of return records and speeds things up by eliminating unnecessary joins. There is still a need for the Data model to do some post-processing of filter parameters, but I think this is an okay pattern.

The problem is that, because we use the data browser to essentially filter every model on every other model (e.g. a site that has c14s from a particular c14_lab), we end up joining everything to everything whichever way we do it. Data.everything is the way we current do this – but hardcoding the entire data structure into this pseudo-model isn't ideal. Or if we filter each model separately, we have to create associations from each model to every other model (e.g. from site to c14_lab and back) – not ideal either.

I can't think of an elegant way of doing this, or away around it. Fundamentally, if we want users to be able to "filter everything" from the data browser, there needs to be some sort of model of "everything" in the application.