Markus,

Hi Walter!

>I think one important issue we've left out previously is whether or not this runs on a network.

I agree there would be some difference in the difference in performance if you run the queries on a network. But still, if there are not many deleted records in table(s) involved in a SQL statement there would no substancial benefit to the tag on deleted().

>In fact, on a network, you might be right with your statement, but only in rare scenarios that involve extremely large amounts of data (a huge number of short records for instance). In this case, just getting the bitmap across the wire may take forever (well, a couple of seconds that is... ;) ).

Again, it does make a difference whether you're app is running on a network or not, But it really does not change very much in my story.

>In general I wouldn't say the Delete() index is humbug. I think most programmers do the right thing if they add that index. If there is a problem, this can always be re-evaluated. But I'm still very confident that in most scenarios this index is a good idea.

I've still got the opposite meaning. If you've got a problem with performance you could look if a tag on deleted will help you.

If you've got several tables in app, you don't add an index for every field in the table. Like you did say yourself, DELETED() can be regarded as a field in a table. I don't see why we should have different rules for DELETED() and other fields in a table.

The rules of adding an index to a table should be the same whether it is an index on a field or a index on deleted().

Walter,