Найти дубликаты в таблице без первичного ключа

У меня есть таблица с тремя столбцами. Первый столбец, определенный как тип varchar, — это номер клиента (c_number), два других также типа varchar — имя и фамилия клиента (c_first_name и c_last_name).

Таблица не имеет отдельного первичного ключа. Но есть дубликаты с одинаковым столбцом c_number (например, для тех же клиентов, но имена и фамилии записаны в разных регистрах).

Количество строк в таблице довольно велико — около миллиона.

Необходимо отобразить всех клиентов, номер которых дублируется более N раз.

Вот код, который решает проблему в лоб:

SELECT *
    COUNT(c_number) AS c
GROUP BY 
    c_number
HAVING 
    (c > N) ;

Но этот подход кажется очень медленным. Мое решение состоит в том, чтобы добавить индекс:

CREATE INDEX idx_c_number 
    ON TABLENAME(c_number);

После этого, если я правильно понимаю, можно будет выполнять выражения для поиска дубликатов в реальном времени.

Если это все еще не так, подскажите, пожалуйста, лучшее решение для поиска дубликатов с наилучшей производительностью (учитывая тот факт, что у нас все еще нет первичного ключа).

Создайте ограничение первичного ключа.

Laurenz Albe 17.11.2022 21:16
ReactJs | Supabase | Добавление данных в базу данных
ReactJs | Supabase | Добавление данных в базу данных
Это и есть ваш редактор таблиц в supabase.👇
Понимание Python и переход к SQL
Понимание Python и переход к SQL
Перед нами лабораторная работа по BloodOath:
2
1
56
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Собственно, "миллион записей" уже не считается "большим"...

Да, индекс позволит вам использовать запрос, подобный описанному вами, с разумным улучшением скорости. «Но ценой…»

Хотя некоторые люди считают «необходимым» или, по крайней мере, «привычным» иметь первичный ключ в таблице, на самом деле это зависит от вас. Некоторые таблицы, например, в основном являются просто «журналами событий или транзакций», и вы никогда не будете использовать «первичный ключ» для ссылки на них. Если вы никогда не будете использовать его, он вам не нужен. В любом случае это не повлияет на «индексацию».

Теперь, создавая этот индекс, вы вводите долгосрочные затраты: отныне индекс необходимо поддерживать. Это приведет к дополнительной стоимости всего, что вставляет или удаляет запись или обновляет проиндексированное значение. Итак, хотя это, конечно, сделает текущий запрос «быстрее», это не бесплатно. «Планируйте соответственно». Только вы можете решить, что лучше для вас. Из-за более серьезных последствий я рекомендую вам обсудить этот вопрос с вашими коллегами, прежде чем продолжить.

Другие вопросы по теме