Нормализация vs Performace: польза / проблемы удаления таблиц связывания в (этой) схеме?

Question

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

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

В основном, допустим, у меня есть таблица объектов. Эти объекты принадлежат определенным людям. У одного объекта может быть один человек, а у других больше 1. Первоначально я думал, как обычно, создать таблицу объектов для моих объектов, таблицу народов для моих людей, а затем таблицу компоновщиков object_to_people.

Однако объединение таблицы объектов и компоновщика для получения всех объектов, на которые назначен человек, может занять до 3 секунд (это основано на записях около 400 тыс., Но только на одну ссылку на объект). Да, я также настроил индекс e.c.t. чтобы попытаться ускорить процесс.

Если я вместо этого удаляю таблицу людей и компоновщика и помещаю людей в таблицу объектов в виде столбцов и использую 1/0, чтобы указать, назначен ли каждый человек этому объекту, не соединяя две большие таблицы, я вижу скорость около 0,3 -> 0,7 секунд (сильно варьируется).

Для начала нам нужно всего 2 человека. Но я не хочу быть слишком строгим, если смогу помочь. Я знаю, что могу использовать кеширование и что, не улучшая тайминги конечного пользователя, но есть ли какая-то причина, по которой это будет считаться действительно плохой идеей - использовать столбцы, а не таблицы ссылок?

Answer 1

У меня похожая настройка.
Моя таблица соединений содержит 17 000 000 строк.Моя таблица "person" содержит 8 400 000 строк, а моя таблица "objects" - 300 000 строк.

У меня есть запросы с несколькими объединениями в моей таблице соединений и объединения результатов, которые возвращают десятки тысяч строк, и они занимают меньшечем 1 секунда, чтобы бежать (50-400 мс).

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

Answer 2

Также в mysql alter table на огромных таблицах может выполняться очень долго, поэтому добавление новых пользователей в приложение будет невозможно в разумные сроки.

Answer 3

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

Answer 4

но есть ли какая-либо причина, по которой это будет действительно плохой идеей использовать столбцы, а не таблицы ссылок?

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

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