Наилучший способ хранения названий элементов, отправленных пользователем (и их синонимов)
Рассмотрим приложение электронной коммерции с несколькими магазинами. Каждый владелец магазина может редактировать каталог товаров своего магазина.
Моя текущая схема базы данных выглядит следующим образом:
item_names: id | name | description | picture | common(BOOL)
items: id | item_name_id | picture | price | description | picture
item_synonyms: id | item_name_id | name | error(BOOL)
Примечания: ошибка указывает на неправильное написание (например, «Ericson»). описание и изображение таблицы item_names являются «глобальными» , которые могут быть при желании переопределены с помощью «local» поля description и picture таблицы items (в случае, если владелец магазина хочет предоставить другое изображение для элемента). общий помогает отделить уникальные названия предметов («Пицца с сыром Джимми Джо» от «Пицца с сыром» )
Я думаю, что яркая сторона этой схемы:
Оптимизированный поиск и обработка синонимов: Я могу запросить таблицы item_names и item_synonyms , используя назовите LIKE% QUERY% и получите список item_name_id , которые необходимо объединить с таблицей items . (Примеры синонимов: «Sony Ericsson», «Sony Ericson», «X10», «X 10»)
Автозаполнение: Опять же простой запрос к таблице item_names . Я могу избежать использования DISTINCT , и это сводит к минимуму количество вариантов («Sony Ericsson Xperia ™ X10», «Sony Ericsson - Xperia X10», «Xperia X10, Sony Ericsson»)
Обратная сторона будет:
Накладные расходы: Когда вставляет элемент, я запрашиваю item_names , чтобы узнать, существует ли это имя уже. Если нет, я создаю новую запись. Когда удаляет элемент, я подсчитываю количество записей с тем же именем. Если это единственный элемент с таким именем, я удаляю запись из таблицы item_names (просто для того, чтобы все было в порядке; учитывает возможные ошибочные представления). И обновление представляет собой комбинацию обоих.
Странные названия предметов: Владельцы магазинов иногда используют такие предложения, как «Гарри Поттер 1, 2 книги + компакт-диски + волшебная шляпа». Есть что-то не так в том, чтобы учесть такие накладные расходы, как этот. Возможно, это основная причина , что я склонен использовать такую схему:
items: id | name | picture | price | description | picture
(... с именами элементов и синонимами элементов в качестве служебных таблиц, которые я мог бы запросить)
- Можно ли предложить лучшую схему?
- Следует ли нормализовать имена элементов для автозаполнения? Возможно ли это то, что Facebook делает для записей "Школа", "Город"?
- Первая или вторая схема лучше / оптимальна для поиска?
Заранее спасибо!
Ссылки: (1) Не заходит ли нормализация имени человека слишком далеко? , (2) Как избежать DISTINCT
РЕДАКТИРОВАТЬ: В случае ввода двух элементов с одинаковыми именами администратор, увидев это, просто нажимает «Сделать Синоним », который преобразует одно из имен в синоним другого. Мне не нужен способ автоматического определения, является ли введенное имя синонимом другого. Я' m надеясь, что автозаполнение позаботится о 95% таких случаев. По мере того, как набор таблиц увеличивается в размерах, потребность в «Сделать синоним» будет уменьшаться. Надеюсь, что это устранит путаницу.
ОБНОВЛЕНИЕ: Для тех, кто хотел бы знать, что я сделал ... Я выбрал вторую схему, но удалил имена_элементов и ] item_synonyms в надежде, что Solr предоставит мне возможность выполнять все оставшиеся задачи, которые мне нужны:
items: id | name | picture | price | description | picture
Спасибо всем за помощь!