Как определить повторяющиеся элементы, собранные из нескольких каналов, и связать их в базе данных

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

Проблема, с которой я столкнулся, заключается в том, что из-за того, что один и тот же продукт указан на многих сайтах продавцом, в моей базе данных появляются повторяющиеся элементы, а затем, когда я показываю их на веб-странице, появляется много дубликатов.

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

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

Как мне идентифицировать появившиеся дубликаты, не замедляя работу всей базы данных? Как бы мне тогда выбрать одно объявление из всех дубликатов, а затем сохранить, на каких еще сайтах оно отображается.

Спасибо за любую помощь.


java database jsp duplicate-data multiple-records
person Max    schedule 25.11.2010    source источник
comment
Пусть правильная реализация Object # equal (Object) и java.util.Set станет вашими друзьями.   -  person Boris Pavlović    schedule 25.11.2010
comment
Plz. Вы можете уточнить, какую базу данных вы используете .. Потому что это будет зависеть от базы данных. Я думаю, вам нужно избегать повторяющихся записей в таблице ... Я прав?   -  person Adalarasan Sachithanantham    schedule 25.11.2010

Ответы (2)


arrow_upward
3
arrow_downward

Проблема двоякая, и обе на вашей стороне. Когда вы поймете, как с этим справиться, напишите код в программу (Java или SQL будет несложно). Я сначала назову их, а затем назову решения.

  1. По какой-то неизвестной причине вы предположили, что сбор описаний продуктов с нескольких сайтов не приведет к сбору одного и того же продукта.

  2. Вы привыкли к общему и бессмысленному столбцу Id, что нормально, когда вы работаете с функциями прототипирования электронных таблиц; но это далеко не то, что требуется для базы данных или функциональности уровня разработки. Ваши пользователи (или начальник), естественно, ожидали от базы данных возможностей базы данных, а вы их не предоставили. (И нет, это не требует логики нечетких строк или какой-либо магии.)

Решение

Это сокращенная версия стандарта IDEF1X для моделирования реляционных баз данных; Часть повторно Идентификаторы.

  1. Вам нужно думать в терминах базы данных и думать о таблицах базы данных, которые вам нужны для выполнения вашей функции, что означает, что вам не разрешено использовать столбец с автоинкрементом Id. В этом столбце электронной таблице присваивается RowId, но он ничего не говорит о содержании таблицы или столбцах, которые идентифицируют продукт.

  2. И вы не можете просто скопировать данные с другого веб-сайта, вам нужно подумать о том, что вашему веб-сайту требуется для продуктов. Что ваша компания понимает под продуктом и как оно идентифицирует продукт?

  3. Определите все столбцы и типы данных для столбцов.

  4. Определите, какие столбцы являются обязательными, а какие - необязательными.

  5. Определите, какие идентификаторы являются надежными. Например. Manufacturer и Model; короткое Product Name, а не длинное Description (или, возможно, для вашей компании длинное описание является идентификатором). Работайте со своими пользователями и работайте над этим.

  6. Вы обнаружите, что на самом деле у вас есть небольшой кластер таблиц вокруг Product, таких как Manufacturer, ProductType, возможно Vendor и т. Д.

  7. Организуйте эти таблицы и нормализуйте их, чтобы не дублировать данные.

  8. Убедитесь, что вы относитесь к этим идентификаторам с некоторым уважением. Выберите, что будет уникальным. Это ключи кандидатов. Вам понадобится хотя бы один на стол, а в Product их будет больше. Все идентификаторы, по которым будет выполняться поиск, должны быть проиндексированы (уникальными или нет). Обратите внимание, что уникальные индексы не могут иметь значение Nullable, поэтому вы не можете выбрать дополнительный столбец.

  9. То, что делает единственный Уникальный идентификатор для Product, не может быть одним столбцом. Это нормально, мы можем оценить несколько столбцов для ключей в базах данных; они называются составными ключами.

  10. Возьмите лучший, самый стабильный (тот, который не изменится) Уникальный идентификатор, один из ключей-кандидатов, и сделайте его первичным ключом.

  11. Если и только если уникальный идентификатор, первичный ключ, который может быть составным ключом, очень длинный и поэтому не подходит для первичного ключа, который переносится в дочерние таблицы, то добавить Суррогатный ключ. Это будет столбец Id. Обратите внимание, что это дополнительный столбец и дополнительный индекс. Он не заменяет идентификаторы Product, ключей-кандидатов; они не могут быть удалены.

На данный момент у нас есть база данных продуктов на стороне вашей компании в Интернете, которая имеет для нее значение. Теперь мы можем оценивать продукты с другой стороны сети; и когда мы это делаем, у нас есть прочная структура на нашей стороне, по которой мы можем измерить мусор, который мы получаем с другой стороны сети.

Каналы

  1. Вам нужна WebSite таблица для управления фидами.

  2. Между Product и WebSite будет ассоциативная таблица (многие-ко-многим). Назовем это ProductSite. Он будет содержать только наши ProductId и WebSiteCode. It may containPrice`. Содержание действительно для одного цикла кормления.

  3. Загрузите каждый канал в промежуточную базу данных или схему, входящую ProductIn таблицу, возможно, по одной на исходный веб-сайт. Это просто плоский файл из внешнего источника. Добавьте столбец IsValid и установите для параметра По умолчанию значение true.

  4. Затем напишите некоторый SQL, который сравнивает эту ProductIn таблицу с ее разрозненным и гибким содержимым с нашей Product таблицей с ее строгими идентификаторами.

    • Я бы сделал это несколькими волнами отдельных проверок, каждая из которых помечала строки, которые не прошли проверку, с IsValid на ложь. В конце вставьте IsValid строк в наш ProductSite.

    • Возможно, вам повезет, и вы выберете оптимистичный подход. То есть, пока вы найдете совпадение в нескольких важных столбцах, совпадение действительно. (измените значение по умолчанию и обновите логическое значение IsValid).

    • Это процедура, которая потребует некоторой работы взад-вперед, пока она не успокоится. Вот почему вам нужно работать с вашими пользователями над идентификаторами. Цель состоит в том, чтобы не исключать никакие внешние продукты, но ваша отправная точка будет исключать многие. Это будет включать возврат к нашей Product таблице и улучшение содержимого (значений в строках) идентификаторов и других соответствующих столбцов, которые вы используете для определения совпадающих строк.

  5. Повторите для каждого веб-сайта.

  6. Теперь заполните наш веб-сайт из нашей Product таблицы, используя информацию, в которой мы уверены, и покажите, на каких сайтах есть продукты для продажи с ProductSite.

person PerformanceDBA    schedule 26.11.2010

arrow_upward
1
arrow_downward

Я не думаю, что это проблема кода или базы данных (пока). Ты говоришь:

Проблема в том, что у предмета нет очевидного уникального идентификатора.

Вам нужно понять, что это за уникальность, прежде чем вы сможете попросить компьютер сделать это за вас. Похоже, вам нужен какой-то нечеткий алгоритм сходства строк.

Некоторые примеры данных, которые вы считаете дубликатами, могут помочь.

person Paul M    schedule 25.11.2010
comment
Я перечитал ваш вопрос в свете ответа PerformanceDBA. Я предполагал, что вы просматриваете экран или имеете доступ только к строке, описывающей продукт. Если у вас есть доступ к отдельным атрибутам продукта, тогда вам подойдет какой-нибудь алгоритм сопоставления / оценки. - person Paul M; 26.11.2010