TomaZ Vazovsky

Модульным наверно уже не является. Я бы назвал его "интеграционным", потому что мы тестируем как работает ваш код совместно с базой.
Суть заключается в том, что мы (в случае записи в базу) подаем на вход методу данные, а потом проверяем, что мы получили в базе, причем без использования нашего кода. В случае чтения наоборот, сначала сторонними средствами создаем записи, а потом проверяем, как они прочитаются.
Я в таких тестах всегда поступал следующим образом:
1. Создаем "дата-провайдера" - который в декларативной форме описывает параметры: "что на входе метода" и "что в базе" или "что в базе" и "что на выходе метода".
2. У нас есть прямой доступ к базе, с помощью него в каждом тесте мы либо создаем запись в базе, либо проверяем, что туда записал тестируемый метод.
Но думаю, такими тестами не стоит сильно увлекаться, ведь они по сути просто проверяют, что вы правильно составили запрос.

Т.е. как я понял, сами данные в этих 9 полях записи, уникальными не являются, но их сочетании должно быть уникальным. Тут в голову приходят пара мыслей.
1. Составное уникальный индекс. Но с несколькими миллионами записей это будет тяжеловато, да и если другой пользы от такого индекса нет, то не лучший вариант, пожалуй.
2. Вариант с хешем, сам хеш под индексом. Тут конечно многое зависит от того, какие данные. Я бы постарался даже не md5 заюзать, а crc32 например, но сам индекс сделать составным с каким-то еще данными, чтобы уменьшить вероятность коллизий, но при этом получить выигрыш по скорости, например если объединить интовый айдишник пользователя и интовый crc32.