Of course this is generally quite reasonable. But in the given case – no deletes on the parent table, no updates of order_number – I think you shouldn’t be that much afraid of locking issues due to FK on order_number.

There are various ways you might have “only 2 distinct values” – so the question comes back to the basic one of indexing: “will the index eliminate more work than it introduces (at the point in time when it really matters) ?”

There’s also the question of whether you have to stick with the current SQL, or whether you can enigineer the code and the indexes at the same time.

For example:

If your two values are ‘N’ and ‘Y’, and nearly all the data has value ‘Y’, then an index on that column could be very helpful for the query “select where col = ‘N’” – but only if you have a histogram on that column.

On the other hand, if you can change the code and data so that it holds ‘N’ or null then you get a tiny index and don’t need the histogram.

On the third hand – if you create the index as (decode(col,’N’.N’,null)) you don’t have to change the code that maintains the data, you get a tiny index, you don’t need the histogram, but you have to modify the code that queries the data so that the queries match the index definition.

Thanks,
Gary