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