Я здесь просто подумал что цена в корзине должна быть зафиксирована при добавлении, и не зависеть от дальнейшего изменения цены товара
Это вообще-то правильно. Но откуда-то она должна же взяться? Вот она есть в таблице товаров, откуда в описанном варианте копируется в таблицу корзины. То есть связь цены в этот момент разрывается (типичное шаблон-инстанс), и теперь цена конкретного экземпляра товара в корзине живёт самостоятельно и независимо от цены товара.
Это не скрин со структурой, а какая-то форма.
Показывай, как это выглядит на уровне SQL-сервера (структуры таблиц CREATE TABLE, пример данных INSERT INTO).
так автор и пытается избежать подобных проблем при конвертации
Да нету их, проблем при конвертации! Ну какая может быть проблема при выполнении UPDATE table SET newcolumn = UNIX_TIMESTAMP(old_column)?
Все проблемы начинаются после того, как клиент получает штамп времени из MySQL и начинает на стороне клиента (там, где работает PHP, JS, Java и пр.) своими немытыми руками преобразовывать полученные значения с учётом клиентской зоны. Пока тип времени был DATATIME - это было сравнительно безопасно. Но когда данные - это UNIX timestamp / INTEGER, любые ручные корректировки способны привести к потрясающим в своем идиотизме результатам. Это сродни перекодировкам в электронной почте... того же порядка проблемы.
Тогда хреновше. На месте не делается. Придётся идти обычным порядком. Создаётся новое поле INT, затем туда копируются данные с конвертацией, затем старое поле убивается, а новое переименуется, и на него натягиваются все индексы, констрейнты и прочая шелуха.
Антон Шаманов, без разницы. Оба типа данных хранятся в UTC.
А если после конвертации софт выдаёт неверные данные - так это проблемы софта, который интерпретировал UTC (DATETIME хранит значение без зоны, что соответствует UTC) как некую иную зону.
В MySQL разница между DATETIME и TIMESTAMP одна-единственная. При получении DATETIME возвращается ровно то, что хранится, а при получении TIMESTAMP значение интерпретируется как UTC и приводится к зоне времени сервера.
Изменение типа данных с DATETIME на TIMESTAMP выполняется мгновенно, поскольку это онлайновая операция, изменяющая только метаданные таблицы и не затрагивающая хранимые данные.
=========================
И всё гораздо хуже, если под "Дата в новом движке хранится в формате timestamp" разумеется хранение в UNIX TIMESTAMP в поле типа INT/BIGINT.
поясните при каких условиях ваше утверждение верно ибо сторонний сервер это ваша терминология а не моя
Не мой это термин, это термин, употреблённый автором ответа, причём в совершенно определённом и вроде бы не допускающем двоякого толкования в контексте основного вопроса смысле... но Вам это удалось.
Да, есть такая дурь как persistent connection. Там для поддержания соединения и сброса таймаута используются "пустые" запросы - что-нибудь типа SELECT VERSION(); или вообще SELECT 1;. Т.е. неважно что, всё равно выбросим, главное - спросить и убедить сервер, что мы ещё не сдохли.
Это вообще-то правильно. Но откуда-то она должна же взяться? Вот она есть в таблице товаров, откуда в описанном варианте копируется в таблицу корзины. То есть связь цены в этот момент разрывается (типичное шаблон-инстанс), и теперь цена конкретного экземпляра товара в корзине живёт самостоятельно и независимо от цены товара.