In Message #796671, Jason Mcfarlane has indicated that he is having problems with slow updates, with one table in particular, which has the following indexes:

Primary Key(Primary)
location_id + depot_code + DTOC(delivery_date) + route_number ;
      + load_number + Str(stop_number, 5) + customer_number ;
      + order_number + product_code + how_requested
not deleted()

location (regular)
location_id

Primary (regular)
location_id + depot_code + DTOC(delivery_date) + route_number ;
      + load_number + Str(stop_number, 5) + customer_number ;
      + order_number + product_code + how_requested

I personally strive to avoid compound keys. From a performance / functionality perspective I see no difference between say a SQL Select with the following WHERE clauses:

cField1 + cField2 = cVal1 + cVal2
 and
cField1 = cVal1 AND cField2 = cVal2

The first is predicated upon a compound index, the Tag can only be used in this single context. The second method has the advantage that each Tag can be used independently or in combination with other Tags. In systems that I have designed compound keys are the exception and not the norm, I would be extremely unlikely to see the same field included in several different tags and being effectively indexed over and over and over (I see 3 instances of location_id above). Does any one else have any thoughts on indexing best practices.