Как я должен вставить / обновить / удалить большие списки в MySQL?

Question

Я пытаюсь найти лучший способ справиться со вставкой / обновлением / удалением больших списков.

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

Чтобы упростить это, вот модель данных (от простого ко многим)

~ 5000 records total
+----------+------------+
| user_id  | user_name  |
+----------+------------+
|        1 | Ralph      |
|        2 | Bill       |
|        3 | Joe        |
|        4 | Mike       |
|        5 | Brian      |
|        6 | Jose       |
+----------+------------+

~ 6000 records total
+------------+------------+
| product_id |   product  |
+------------+------------+
|          1 | Widget A   |
|          2 | Widget B   |
|          3 | Widget C   |
|          4 | Widget D   |
|          5 | Widget E   |
|          6 | Widget F   |
+------------+------------+

As many as 30 million total
+----------+------------+
| user_id  | product_id |
+----------+------------+
|        1 |          1 |
|        1 |          4 |
|        1 |          6 |
|        2 |          2 |
|        2 |          4 |
|        2 |          5 |
+----------+------------+ 

Проблема в том, что продукты выбираются оптом, поэтому, если пользователь нажимает, выбирают все (что они часто делают), они выбирают около 6000 продуктов, что соответствует большому запросу вставки.

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

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

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

Я решил вместо хранения продуктов, которые нужны пользователям, хранить только продукт, который не нужен пользователю, тем самым ограничивая накладные расходы при частых больших запросах на вставку / обновление.Таким образом, каждый пользователь получает каждый продукт, доступный по умолчанию.

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

Большое спасибо тому, кто может мне помочь.

Редактировать: просто для пояснения, пользователи не ограничены только критериями выбора.Они также могут напрямую выбирать товары и группы товаров.Пользователи уникальны тем, что все они хорошо знакомы с продуктами (большинство знают почти все 6000 наименований).

Answer 1

Возможно, вы захотите сохранить критерии выбора вместо самих продуктов.Например, храните "price <10 и category =" sports "" вместо хранения (возможно, длинного) списка продуктов, которые соответствуют этим критериям.Затем вы можете воссоздать список, применив критерии выбора к текущему списку продуктов. </p>

Вам необходимо выяснить, какой синтаксис следует использовать для хранения критериев.Может быть, SQL будет работать, может быть, вам нужно что-то еще.Модификации могут быть хитрыми, вам нужно будет применить некоторую простую логику, чтобы смягчить это, например, критерии должны быть ИЛИ И для простых сравнений полей / значений.

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

Answer 2

Не могли бы вы добавить дополнительный столбец REPORT_ON в таблицу сопоставления? Строки в этой таблице останутся более или менее статичными, и вам нужно будет просто обновить отдельные строки и пакеты строк, когда пользователь активно изменил критерии.

Answer 3

Другая возможность - разделить таблицу users-products. В MySQL 5.1 добавлена ​​поддержка секционирования таблиц:

http://dev.mysql.com/doc/refman/5.1/en/partitioning.html

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

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