Это вопрос о производительности, а не о возможных решениях.
Моя система содержит много предметов разных категорий. Каждая категория имеет свою собственную таблицу, так как каждая таблица имеет много строк И поля разные.
ItemA - id, fld1, fld2
ItemB - id, fld1, fld3, fld4
ItemC - id, fld1, fld3, fld5
....
Теперь необходимо управлять пользовательским инвентарем, то есть есть у пользователя предмет или нет. Один из вариантов использует одну таблицу:
Inventory - category_id, item_id, user_id
category_id отличается для строк ItemA, ItemB,..., и именно так мы различаем.
Второй вариант - иметь:
InventoryA - item_id, user_id
InventoryB - item_id, user_id
...
Первый вариант, вероятно, самый простой в управлении, НО инвентарная таблица огромна (порядок величины: количество элементов во всех категориях, умноженное на количество пользователей), часто обновляется и часто запрашивается.
Вторым вариантом будет немного сложнее управлять (поскольку мы создаем новую таблицу инвентаря для каждой категории), но он может дать прирост производительности, поскольку может предотвратить условия гонки. Ни один запрос, скорее всего, не потребует включения более одной таблицы инвентаризации, поскольку категории достаточно разделены.
В настоящее время система использует MySQL и движок InnoDB. Есть около 10 категорий, но ожидается, что в ближайшем будущем их станет несколько десятков. Самая большая категория содержит > 200 000 элементов, а большинство из них – > 10 000 элементов. Единая таблица инвентаризации содержит > 10 миллионов строк и, как ожидается, станет НАМНОГО больше по мере присоединения большего числа пользователей.
Я знаю, что лучше всего проверить производительность обоих методов и принять решение, но правда в том, что переход на многотабличный дизайн не будет таким быстрым и безболезненным.
Если у вас есть личный опыт решения подобной проблемы, поделитесь им.
Спасибо
