>>>>If yes, you may have to calculate relative weight (or what's the right term? "удельный вес" in Russian) of each duplicate to the total number of records removed from each particular table...
>>>>
>>>>Anyway, let's see, if this is the exact problem you're trying to solve, because now I can see the complexity.
>>>
>>>Why complexity? You calculate number of duplicates that needs to be deleted, then you calculate the deletion number for each of 4 tables, and then you scan and delete in each table counting delete total until you get the number. Obviously, during deletion you should reduce the total duplicate counter to keep the last record intact.
>>
>>What if we also want to somehow keep the original table sizes proportions?
>>
>Yes, one must calculate total number of dupicates, then calculate how many 'duplicates' are in each table and then get the proportion/weight: i.e. delete 120 records in table1, 282 in table 2 etc.
>
>>I want to first hear the exact problem definition with some samples, then we can think of a solution.
>
>Absolutely.

What makes it so complex is this: there will be a large number of different sets of duplicates. E.g. there are 129 sets of duplicates in table 1 and 2, 62 in table 1 and 3, 112 in 1 and 4, etc. with all permutations of 1,2,3 and 4. Because of that, once starting to delete duplicates in the end-result, you come to a situation where there are no records left to delete from table X, so you have to backtrack, deleting records with origin table X from sets where records from table X were left undeleted, thereby 'recalling' records from other tables which were deleted. This makes it very complex, especially since this is only an example of 4 tables, but I need an algorithm for T tables.

To make it a little easier: there are no duplicates within one table.

Hopes this makes it a bit more clear.