Target Database Model Improvements for Stratum Integrity: A Stratum Constraints Table and Loading functions #402
Description
Related to Issue #401 , we should design our database and loading functions so that it is difficult to load targets that cause issues later in development. Issue #401 calls out the problem that child strata don't have to be logically related to their parent strata; they only have to be unique. In a similar vein, constraints don't have to make sense, they just have to be different in each stratum.
A stratum_constraints table would be a first step to preventing these problems. For instance, if "griter_or_equal_to" was not in that table, it should not be usable in the strata table.
Even if we have a standard set of constraints, we can still have an inconsistent set, say, a stratum with "greater_than_or_equal_to" set to 3 and "less_than" set to 1. It's unlikely that we'll be able to find something in the data model that could prevent this, but like in Issue #401, these inconsistencies could be checked at load time with a common function.