>>>>>Edward,
>>>>>
>>>>>I think the problem is that you might run out of records to delete from the latter tables, maybe the process should start with the tables ordered by the number of records to delete to minimize this.
>>>>>
>>>>>Ex. (r records and d records to delete)
>>>>>
>>>>>T1: 500r 30d
>>>>>T2: 100r 10d
>>>>>T3: 111r 3d && You might already run out of duplicates to delete from this table
>>>>
>>>>That's a good idea. It makes sense to start from the table with the minimum number of required deletions. As I mentioned before, exact result, i.e. absolutely correct proportion is not reachable, so one should try to get the best randomization.
>>>
>>>I have the feeling there is a mathematically best solution. Because the way records will be deleted affects real business money, and because a solution like yours we programmed left us with differences from the optimal solution in the range of 3-7%, I'm afraid our customers will not be satisfied.
>>>
>>>My experience says I have to look in the direction of a recursive algorithm. That's fine, but my experience won't come with that algorithm. It reminds me slightly of the problem of 8 queens on a chess board, relatively easy to solve with recursion.
>>>
>>>This problem however adresses thousands or even tens of thousands sets of duplicates spread over all permutations of T tables. The chess board and the number of queens is quite big.
>>
>>Could you remind me 8 queens puzzle, if you don't mind?
>
>Put 8 queens on a chess board in such a position they can't attack one another.

Thank you.