Можно ли иметь все связанные столбцы в одной таблице? Может ли запрос выбора для нескольких таблиц повлиять на производительность?

Question

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

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

Опция 2: Чтобы иметь две таблицы (для процесса 1 и 2) и вставлять данные записей (связывая их с первичным ключом) по мере продолжения процесса.

Какая опция имеет лучшую производительность при вставке данных? INSERT + UPDATE в одной таблице или INSERT в двух таблицах. Столбцы тесно связаны между собой.

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

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

Answer 1

С точки зрения производительности, один стол - лучший вариант. Для получения данных из двух разных таблиц потребуется объединение, что снизит производительность. Однако все зависит от использования данных из таблицы, таких как данные. Иногда для улучшения денормализации производительности это лучший вариант.

С точки зрения лучшей организации целесообразно разделить данные на две таблицы. Указывает, для какого типа данных таблица обновляется. Или, проще говоря, цель таблицы.

Answer 2

INSERT ON DUPLICATE KEY UPDATE или REPLACE в одну таблицу быстрее, чем две вставки. SELECT из одной таблицы быстрее, чем SELECT из двух таблиц с объединением, даже если это объединение хорошо оптимизировано. Поэтому, если ваше приложение всегда обращалось ко всем данным в записи, у вас должна быть одна таблица.

Однако, если ваше приложение обычно обращается только к небольшому подмножеству записи, и ваши чтения происходят намного чаще, чем ваши записи (очень распространенный сценарий), то лучше разбить запись на две таблицы, потому что Ваш общий случай (прочитайте небольшое подмножество полей) будет значительно улучшен по мере увеличения размера данных - достаточно, чтобы компенсировать дополнительные издержки при менее частых операциях записи и полных чтениях.

Это будет иметь особое значение когда размер всего набора данных превышает объем физической памяти, где он может быть кэширован. Тогда в сценарии с двумя таблицами вы все еще можете расти, скажем, в 10 раз, и ваш общий случай - доступ к небольшому подмножеству столбцов - все еще в основном читает из ОЗУ, в то время как в сценарии с одной записью вы уже начинаете читать с диска даже когда вам нужно всего несколько столбцов, что приводит к разнице в производительности в 1000 раз.