Разработка базы данных для агрегатора продуктов

Question

Я пытаюсь создать базу данных для агрегатора продуктов. Каждый продукт имеет информацию о том, откуда он, сколько он стоит, что это за товар, цена, цвет и т. Д. Пользователи должны иметь возможность искать и фильтровать результаты по любой из этих категорий продуктов. Я также ожидаю иметь большое количество пользователей. Первоначально я думал, что у меня будет одна большая таблица с каждым продуктом, в которой будет столбец для каждой части информации и индекс для всего, что мне нужно для поиска, но я думаю, что это может быть неэффективно, так как многие пользователи стучат по этому. Таблица. Моя другая мысль состояла в том, чтобы организовать базу данных для продвижения древовидной навигации по таблицам, но поскольку вы можете искать по чему угодно, я не уверен, как бы я организовал таблицы.

Есть какие-нибудь мысли по поводу хороших практик?

Answer 1

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

(из комментариев)

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

Некоторые из этих атрибутов будут внешними ключами для таблиц поиска, другие (цена) будут простыми скалярами. Соответствующая индексация и у вас все будет хорошо. Для расширенной аналитики рассмотрите размерно-смоделированную звездообразную схему, но, возможно, не для вашей действующей системы транзакций - это зависит от того, каков ваш поток данных / рабочий поток / транзакции. Или рассмотрите некоторые преимущества его принципов в вашей транзакционной базе данных. Ральф Кимбалл - источник хорошей информации о многомерном моделировании.

Answer 2

Одна таблица для продуктов и другая таблица для иерархии категорий продуктов (вы конкретно не говорите, что у вас это есть, но «древовидная навигация по таблицам» заставляет меня думать, что вы можете).

IЯ могу видеть, что вы можете быть обеспокоены чрезмерной индексацией, вызывающей проблемы, если вы планируете индексировать почти каждый столбец.В этом случае может быть лучше индексировать по верхним 5 или 10 столбцам, которые, по вашему мнению, пользователи будут искать, если только пользователь не может выполнить поиск по ЛЮБОМУ столбцу.В этом случае вы можете посмотреть на создание хранилища данных.Может быть, вы захотите взглянуть на кубы данных, чтобы увидеть, помогут ли они ...?

---

Для иерархических данных вам нужна таблица PRODUCT_CATEGORY, которая выглядит примерно так:

ID
PARENT_ID
NAME

Некоторые примеры данных:

ID     PARENT_ID     NAME
1                    ROOT
2      1             SOCKS
3      1             HELICOPTER PARTS
4      2             ARGYLE

Некоторые механизмы SQL (например, Oracle) позволяют писать рекурсивные запросы для обхода иерархии в одном запросе.В этом примере корень дерева имеет PARENT_ID из NULL, но если вы не хотите, чтобы этот столбец обнулялся, я также видел, что -1 использовался для тех же целей.

Answer 3

Для текстового поиска и простоты запуска и дизайна я настоятельно рекомендую Apache SOLR.SOLR API прост в использовании (особенно JSON).Базы данных плохо выполняют поиск текста, и я бы порекомендовал вам просто убедиться, что они правильно отвечают на запросы первичного / уникального ключа, и это те поля, которые вы должны индексировать.

Answer 4

Я не вижу здесь никакой необходимости в древовидной структуре. Вы можете сделать с одним столом.

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