Настройка первичных ключей в моих таблицах?

Question

У меня есть несколько таблиц, которые генерируются разными системами без уникального идентификатора, доступного для необработанных данных.

несколько файлов, которые из одной и той же системы могут быть объединены на основе:

interaction_time, customer_id, employee_id 

Другие файлы не включают в себя метку времени и есть только interaction_date. Проблема в том, что иногда один и тот же клиент может разговаривать с одним и тем же сотрудником в тот же день несколько раз. Поэтому использование interaction_date, customer_id, employee_id не обязательно уникально.

Использование python (pandas), что я обычно делаю, это найти все уникальные значения interaction_date, customer_id, employee_id. Я фильтрую эти строки как отдельный фрейм данных и делаю свои объединения. Таким образом, эти данные представляют собой строки, в которых один клиент взаимодействовал с одним сотрудником один раз в определенную дату. Затем я объединяю/присоединяю строки, которые имеют несколько взаимодействий, вместе с данными, добавленными после объединения.

Любые рекомендации относительно того, как установить что-то подобное с SQL Server? Я предполагаю, что это должно быть довольно распространенным явлением. Я строю таблицы прямо сейчас, и я не уверен, каким должен быть мой первичный ключ ... составной ключ даты/customer_id/employee_id? Как мне работать с дубликатами (эти строки нельзя присоединить к другим файлам, потому что нет четкого способа связать данные вместе)?

edit- Я просто хотел добавить, что это связывает самые гранулированные данные, которые у нас есть. Это будет использоваться для привязки опроса (который может быть получен спустя несколько недель) обратно к определенному взаимодействию и для привязки другого файла, который имеет длину этого взаимодействия, и другого файла, имеющего возможность продажи в этом взаимодействии, и т.д.

Answer 1

Поскольку даже interaction_time, customer_id, employee_id не однозначно определить значения в базе данных, вы можете сделать две вещи:

1) не делайте первичный ключ на всех (хотя это плохая практика)

2) Сделайте полевой вызов как interaction_id, который однозначно определит взаимодействие между потребителем и сотрудником. Это поле может быть настроено на автоматическое увеличение.