Что более оптимально? Объединить 2 таблицы или использовать дополнительный столбец в таблице

ProgramBox

Что более оптимально? Объединить 2 таблицы или использовать дополнительный столбец в таблице

Post author:admin
Запись опубликована:23 февраля, 2023
Post category:Вопросы по программированию

#mysql #database #performance #left-join #tablecolumn

#mysql #База данных #Производительность #левое соединение #tablecolumn

Вопрос:

Таблица A1:

 | id | name  | code | level |
|  1 | Anton | A111 |     2 |
|  2 | Berta | A112 |     5 |

Таблица B1:

 | id | name  | code |
|  1 | Anton | A111 |
|  2 | Berta | A112 |

Таблица B2:

 | id | code | level |
|  1 | A111 |     2 |
|  2 | A112 |     5 |

Что более оптимально?

используйте таблицу A1 (столбец уровня):

 SELECT 'id,name' FROM A1 WHERE level=2;

или

используйте таблицу B1 и таблицу B2 путем объединения (столбец кода):

 SELECT 'id,name' FROM B1 LEFT JOIN B2 ON B1.code=B2.code WHERE level=2;

спасибо.

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

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

3. Вы также должны иметь в виду, что ОБНОВЛЕНИЯ будут фиксировать блокировку в InnoDB.. При использовании метода @TimBiegeleisen (нормализованный) это будет означать меньшую блокировку записей, чем в денормализованных таблицах.. Если вы хотите обновить что-то вроде кода в денормализованных таблицах, MySQL (InnoDB) будет блокировать запись большей части таблицы, что не очень хорошо, когда приложению или таблице необходимо обрабатывать множество одновременных пользователей (быстро)

4. Этот вопрос направлен в сторону «в первую очередь на основе мнений» и тяжелой базы данных, которая является слишком широкой. Для таких вещей, как ORDER BY table1.column, table2.column денормализованная модель с индексами, быстрее, поскольку MySQL не может хорошо оптимизировать a ORDER BY для двух отдельных таблиц.. Итак, вам нужно будет имитировать стандарт SQL 2003 , который называется материализованным представлением

5. Для объединения информация о соответствующем столбце обычно фиксирована (например, столбец ID)! @RaymondNijland

Ответ №1:

Общий ответ на ваш вопрос заключается в том, что предпочтительнее работать с двумя отдельными таблицами, а не с объединенной / комбинированной версией A1 . Причиной этого является принцип нормализации. Рассмотрим ситуацию, когда заданное имя / код соответствует более чем одному уровню, например, это B2 :

 | id | code | level |
|  1 | A111 |     2 |
|  1 | A111 |     3 |
|  1 | A111 |     4 |
|  2 | A112 |     5 |

Теперь объединение приведет к следующей таблице:

 | id | name  | code | level |
|  1 | Anton | A111 |     2 |
|  1 | Anton | A111 |     3 |
|  1 | Anton | A111 |     4 |
|  2 | Berta | A112 |     5 |

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

Одним из возможных оправданий использования A1 таблицы было бы, если вам нужен молниеносный запрос для извлечения вашей информации, и вы хотите избежать объединения. Но, прежде чем вы попадете в этот случай, вы бы сначала изучили такие вещи, как индексы, которые обычно могут ускорить процесс, прежде чем прибегать к денормализованным схемам таблиц.

1. Хранение — это одно, но это может быть не причиной, по которой вы выбрали модель A. Скорее всего, вы бы выбрали модель A, потому что вам нужна очень высокая производительность select. В общем, вы всегда должны нормализовать свои данные в SQL.

2. @AminMaleki Метод B (денормализованный) заблокирует большую часть таблицы, если вы что-то обновите., Метод A (нормализованный) должен обеспечить (намного) лучшую производительность при работе с большим количеством одновременных пользователей

Ответ №2:

Первый случай (с одной таблицей) будет работать быстрее. Кроме того, у вас есть ключ varchar в первом случае, запросы SELECT будут работать медленнее, чем с целочисленными ключами.

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

Например, у вас есть таблица Users с полем town_id и таблица Town с town_name . Быстрее запрашивать информацию о пользователе и название города, если название города хранится в таблице пользователя.

1. «Второй случай (с одной таблицей) будет работать быстрее» Операторы ВЫБОРА — это не единственное, что выполняется в таблице, на самом деле, скорее всего, следование этому предложению замедлит работу приложения / таблицы при обработке большого количества одновременных пользователей и ОБНОВЛЕНИЙ, см. Мой комментарий под вопросом topicstarter почему..

2. Поэтому, если мне нужно иметь один или два столбца (с фиксированными данными), модель A — лучший вариант с небольшим объемом памяти. В противном случае модель B является лучшим вариантом.