Лучше делать перезапись в столбец или оставлять вычислением?
Столкнулся с такой мыслью.
У нас есть столбец, значения которого мы можем вычислять для получения результата.
(взять значение одного, сложить с другим, умножить на третье и добавить четвертое).
Но не будет ли лучше, если мы его будет всегда перезаписывать и сохранять для поиска по нему в отдельном столбце?
Или подсчёт 2-4 значений из разных столбцов не нагружают особо БД и лучше это значение оставить вычисляемым?
Оно получается будет, как уже записанное, а вычисляться только, если мы в одном из значений столбцов поменяем значение?
Т.е. вычисляется оно один раз при смене данных в БД, а при запросе пользователей будет уже поиск и сравнение по готовому столбцу/таблице без лишних вычислений?
VIRTUAL: Column values are not stored, but are evaluated when rows are read, immediately after any BEFORE triggers. A virtual column takes no storage. InnoDB supports secondary indexes on virtual columns.
STORED: Column values are evaluated and stored when rows are inserted or updated. A stored column does require storage space and can be indexed.
Igorek98, В документации всё описано. Учитесь читать. VIRTUAL нигде не хранится, вычисляется при чтении строки. STORED хранится в таблице как обычное поле, вычисляется при вставке/изменении строки. А название полю вы сами даёте.
Rsa97, Если я правильно понял, то в обычной таблице при создании можно какие-то столбцы создавать генирирующимися и они будут сами обновляться по мере изменения других колонок от которых зависят?
Rsa97, а как быть с таким моментом, что, если у нас одно из значений будет ровно 0, а умножив на 0, мы ничего не получим, как нам тогда при этом значении сделать эквивалент, что мы просто пропускаем тогда умножение? Например, когда речь заходит о процентном соотношении.
Тут стоит исходить из того, что операции create/update происходят единожды и с одной конкретной строкой, в отличие от того же чтения. Гипотетический пример: у нас есть N записей, для их создания нам N раз придется складывать M столбцов. Допустим, что таблица у нас неотсортированная и без индексов. Тогда для поиска одного элемента нам придется в среднем N / 2 раз сложить M столбцов, что уже даже при единичных операциях поиска убьет весь наш "выигрыш" от отказа вычислять эти столбцы при создании/обновлении. Выбор очевиден
