Each filter tag has multiple records. We find the one where our transaction amount falls between minimum and maximum, and where step applies (this is based on price movements). If we find a matching row, we let the transaction through, otherwise we reject it.
If however, our transaction doesn't fall between any of the min/max amounts, or the stepping doesn't match, we also reject that transaction.
Note that in the first table, each tag can occur multiple times - each rule falls through from top to bottom.
In the second table, each tag can also occur multiple times - each tag will have different min/max/step values.
Also, each tag may be used by different clients, hence the separation into two tables.
My question is to the database gurus out there - what's the best way to design these tables to take better advantage of the database, and provide some better validation?
I assume there's a M2M relationship between the two tables - with the intermediary table storing 'tag', right?