В любом случае, использование Select ... Group By ... Having здесь может здорово помочь.
Подробнее - http://khpi-iip.mipk.kharkiv.edu/library/dbms/kir2/2-5.html
а также - http://khpi-iip.mipk.kharkiv.edu/library/dbms/kir2/3-6.html

Один нюанс:
Необходимо, чтобы Ф.И.О каждого клиента вводилось строго ОДНООБРАЗНО, т.е., скажем, отчество ВИТАЛЬЕВИЧ и ВИТАЛИЕВИЧ должно иметь только ОДИН вариант ввода, иначе запрос сгруппирует этого клиента как 2-х совершенно разных людей. А если учесть все возможные варианты написания фамилий, то там вообще тушите свет! Простейшим способом обойти это не удасться. Придется написать код, который будет сверять приблизительное подобие вводимой информации с уже введенной и предлагать право выбора оператору при хотябы относительной похожести. Трудновато придется при разработке такого кода, знаю по своим разработкам аналогичного назначения. Но если этого не сделать - запросто может получиться, что постоянный клиент недополучит скидки :(

Да я не против нормализации :) Просто вы, Игорь, сами же из двуязычного региона, и безусловно знаете, сколькими разными способами юзеры умудряются ввести одну и ту же фамилию, имя, отчество. И в каком бы файле они ни находились - в справочном или в общем - процедура сверки все равно необходима. А сверяться-то будет вводимая полуграмотным юзером информация. И один Бог наперед знает, насколько правильно он ее введет. А, следовательно, и результат сверки и отождествления(идентификации) клиента вовсе не гарантируется на 100%. Именно поэтому я для себя когда-то написал процедуру выборки, которая выбирает те записи, в которых хотя бы 75% символов (задаваемая величина) в контролируемом поле совпадает с введенным пользователем сомнительным "образцом". А затем уже из предъявленного множества "подобий" по дополнительным полям можно сориентироваться, тот ли самый это клиент или нет. Может, это и кустарщина, зато в моих базах теперь действительно редко появляются "необоснованные дубли"