@adam_k's advice is IMHO correct for small-scale apps.
This scenario is a data administrator's nightmare called a fuzzy relation. It's not really a relation at all strictly speaking. It depends on evaluating values in order to establish relevance to a set. It doesn't really belong in your data structure, and frankly it shouldn't even be in a single statement...getting the price data based on a value range is a programmatic task that should require two SQL statements.
A sample select from @adam_k's suggestion would look something like this:
select * from wiring
left join pricelist
on Power >= PowerMin
and Power <= PowerMax
As you can see, this statement would cause a cartesian product which would then have to be constrained by the values in Power, PowerMin and PowerMax. Ewww. Very expensive query to run. If you had a lot of data this would slow your app to a crawl. For small amounts of data it would be okay, but not good practice.
What follows this as a sort of "academic exercise" so you understand the issues. My guess is that it is overkill for your scenario, so feel free to disregard it.
If you really want to nail down the relation between Wiring and PriceList, you could do something like:
PriceList(Bracket, PowerMin, PowerMax, Price)
Wiring (WiringID, <em>Bracket (fk to PriceList)</em>, Power)
This enforces actual referential integrity between your Wiring and your PriceList, allows you to keep your discrete ranges on your price list, and keep your actual Power number for the Wiring.
Bad news is you have to programatically assign the proper Bracket, either in your code (combo box or selection list?), or a stored proc or a trigger. However, once it's assigned you don't have to worry about doing the comparison later, just follow the foreign key. This might become significant if you are dealing with large quantities of data.
Again, probably overkill but what the heck...we're all about learning here, right?
Anyway, good luck!
