alexeyvgChAФормально, "корзине покупателя" вообще нечего делать на сервере, до тех пор пока вы не превратите список желаемых товаров волшебной кнопочкой в заказ. Только на этом этапе товар может быть зарезервирован в БД, заодно можно получить отлуп, если каких-то товаров уже нет в магазине и будет дана возможность скорректировать заказ. После удачного прохождения этой процедуры данные заказа, включая ассортимент, цену и количество фиксируется в БД. А пока всё на стадии "а не купить ли мне...?" резервировать товар слишком накладно.Обычно получается так, что дешевле и проще делать одну структуру и для корзины, и для заказа.

Иначе получится тупо две совершенно одинаковых структуры, и два набора совершенно одинакового кода для работы с ней.
А в случае "куков", или подобных отличающихся от хранилища заказов механизмов - ещё и разные методы работы с хранилищем данных для этих двух одинаковых структур данных.

Проще сделать стандартную двухтабличную структуру "Заголовок заказа" - "детали заказа", и использовать её везде.
Корзина (пред-заказ) и оформленный заказ - это разные понятия, которым присущи разные атрибуты. Например, "оплачен/забронирован". Вы предлагаете хранить NULL для товаров из корзины? А реляционная теория NULLs не любит. А мы тут вроде про проектирование говорим, т.е. про принципиальные и идеологические вопросы.
А еще могут быть внешние ключи на дочерние сущности. И как для обеспечения целостности на уровне БД определить, к какой записи в таблице можно привязать дочку (скажем, наряд на отгрузку), а к какой - нельзя, потому что это всего лишь предзаказ? Делать составной ключ, включающий некое поле "СТАТУС", и на дочерней таблице вешать CHECK CONSTRAINT на это поле?

И самое главное различие заключается в том, что по своей природе корзина - это транзитная очередь. Она наполняется и опустошается. А оформленный заказ - это история, влитая в гранит. Одного этого достаточно, чтобы разделить эти понятия. Делается ли физическое удаление записи из очереди (корзины) или просто пометка - суть не в этом. Для оформленного заказа статус "актуален" неприменим, как бы он ни реализовывался.

ChAФормально, "корзине покупателя" вообще нечего делать на сервере, до тех пор пока вы не превратите список желаемых товаров волшебной кнопочкой в заказ. Только на этом этапе товар может быть зарезервирован в БД, заодно можно получить отлуп, если каких-то товаров уже нет в магазине и будет дана возможность скорректировать заказ. После удачного прохождения этой процедуры данные заказа, включая ассортимент, цену и количество фиксируется в БД. А пока всё на стадии "а не купить ли мне...?" резервировать товар слишком накладно.
Почему это нечего делать в БД? Корзина - это результат действий пользователя, зарегистрированного в БД, которые структурированы и подлежат анализу. Например, по наличию записей в корзине можно делать выводы, чем интересуется клиент, и что ему предложить в следующий раз.
Просто речь идет о сущности, отдельной от сущности "заказ". Назовем это "Желания клиента".

Анализ предпочтений клиента лучше по оформленным заказам делать, так что мой пример был неудачным. В любом случае, это некая информация, которая в ряде случаев может иметь важное значение. Например, корзина растет по всем покупателям, а заказы не оформляются. Почему? А может, не успевают оформлять, товар у них из-под рук выдергивают. Вывод - мало товара, нужно на складе иметь больше. Или хреново реализован механизм бронирования. Может быть, есть какие-то проблемы с оплатой на сайте, и народ бросает заполненные корзины, не доводя покупку до конца.
Все это дает возможность анализа в разных разрезах. Нет информации - нет анализа. Сиди и догадывайся.