Я не уверен, что вопрос полностью понятен. Если вы хотите вести историю кинематики, то подходящей структурой будет нормализация данных в данные автомобиля и данные о курсе. Данные об автомобиле могут обновляться независимо и, вероятно, будут намного меньше, чем данные кинематики.
Если вы хотите сохранить фиксированную запись с текущим состоянием автомобиля, а не вести историю, оставьте данные, как они, скорее всего, будут быстрее. Причина этого заключается в том, что запись всей записи, вероятно, повлечет за собой всего лишь одну операцию записи в большинстве случаев. Разделение его на две таблицы гарантирует, что будет по крайней мере две операции записи.
В первом случае вы просто нормализуете данные; во втором случае текущая структура данных, вероятно, наиболее эффективна.
Вертикальное разбиение на самом деле не так часто используется (за исключением случаев, когда это происходит, см. Ниже). Некоторые сценарии, где вы можете использовать вертикальное разбиение:
Таблица очень широкая, и только некоторые из них используются часто. Например, если у вас есть таблица с 250 столбцами, 5 из которых регулярно обновляются, а небольшое подмножество столбцов часто используется приложением.
По соображениям безопасности у вас может быть смесь конфиденциальных и не очень конфиденциальных данных, которые находятся в отношении 1: 1. Вы можете переместить конфиденциальные данные в другую таблицу с другим набором разрешений. Исторически не все платформы СУБД позволяли устанавливать разрешения на уровне столбцов.
Комбинация двух предыдущих, где изменения в определенных полях должны регистрироваться в таблице аудита, но другие поля обновляются очень часто без необходимости ведения журнала. Чтобы избежать создания большого количества ложных данных журнала аудита, проверяемые поля могут находиться в своей собственной таблице с триггерами журнала аудита.
Наконец, вы получаете вертикальное разделение за кулисами при определенных обстоятельствах (то есть это не является явным в схеме, но физическое хранилище работает таким образом). Например, многие платформы СУБД хранят большие объекты отдельно от обычных данных таблицы, что приводит к неявному вертикальному разделению таблицы.
Фактически, эта конкретная ситуация делает таблицы со столбцами больших объектов довольно дорогими для выполнения операций, поэтому перемещение столбца больших объектов в отдельную таблицу вполне может быть хорошим приложением для вертикального разделения.
Существует не так много применений для вертикального разделения, и это всегда добавляет накладные расходы на дополнительный ввод / вывод. Вам нужно избегать больших накладных расходов или иметь конкретные причины, например, проблемы безопасности, так как есть много смысла в их использовании.