Более совершенный - две таблицы или один

Question

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

данные выглядит примерно так:

Title  Platform 
Terminator 1 
Terminator 2 
Abyss   1 

Я хочу, чтобы выяснить такие вещи, как «Покажите мне все названия, которые находятся на платформе 1, но не 2 (» Бездна «)», «Показать мне все названия, которые находятся на обеих платформах («Терминатор»), Покажите мне все заголовки, которые находятся на платформе 2, но не в платформе 1 (NULL).

У меня есть только две платформы для сравнения: 1 и 2. Должен ли я хранить все данные в одной таблице или хранить их в двух отдельных таблицах с одинаковой структурой? Что обеспечило бы лучшую производительность?

Answer 1

Я думаю, что в основном это зависит от эффективного использования индексов и правильных запросов. Разделительные таблицы, или using partitions to divide table data, являются лишь достойным решением, когда действительно имеется много данных.

Разделение или разметка полезно при наличии (очень) больших строк или исторических данных, что вызывает проблемы с кешем памяти. Вы можете рассчитать это сами: для миллионов строк в 1 КБ требуется 1 ГБ памяти для загрузки полной таблицы. Если вы используете индекс и база данных должна читать «всего» 100 строк, ему требуется 100 КБ.

Мои 2 цента: держать его таким образом, и проверить возможности оптимизации с помощью индексов и т.д.

Answer 2

Если это те три запроса, которые вы должны ответить, и вы должны ответить на них быстро, то я хотел бы предложить менее нормализуется маршрут:

• Название
• IsPlatform1
• IsPlatform2

(Конечно, это меньше возможности, если есть дополнительная информация для каждой платформы.)

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

«Недостаток» - если он один - это операция, которая была insert, теперь будет update. На самом деле MySQL имеет очень удобный синтаксис insert . . . on duplicate key update, чтобы справиться с этой ситуацией очень хорошо.

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