AlexRFТобишь, когда пользователь жмет заказать такой то товар, выбирает его, то создается заявка со статусом "в работе", соответст. в табл состав заявки уже пишется idшник, и к нему добавляются товары. так?Ещё вариант - сделать отдельную структуру для "корзины".

Тут нужна такая же структура, как и для заказа, только без самой таблицы заказов (в простом случае это будет таблица "Товары в корзине" с ссылкой на пользователя).

Когда пользователь прошёл всю цепочку процесса заказа, начинается формирование заказа - создаётся запись заказа и товары переносятся в соответствующую таблицу.

Такой подход удобен тем, что товары в корзине сохраняются от сессии к сессии, корзина существует постоянно, не нужно после перерыва читать все заказы пользователя со статусом "в работе", вообще не нужно ничем заморачиваться.
Это в том случае, если вообще есть понятие "пользователь". Если такого понятия нет (например, анонимные заказы с сайта), то можно использовать подход Кот Матроскин

AlexRFalexeyvg,

есть пользователь, но у пользователя может быть много заявокВ смысле, много корзин, в которые до окончательного оформления заказа он накладывает товары?

Тогда правильный вариант Кот Матроскин, он более гибкий, позволяет работать со сложной бизнес-логикой (которая нужна, допустим, для оптовиков, закупок и т.п.)
Кот МатроскинalexeyvgТакой подход удобен тем, что товары в корзине сохраняются от сессии к сессии, корзина существует постоянно, не нужно после перерыва читать все заказы пользователя со статусом "в работе", вообще не нужно ничем заморачиваться.

Эээ, а что мешает при моем подходе сохранять товары в корзине от сессии к сессии?Я же писал, что ничего не мешает. Просто придётся реализовывать специальные алгоритмы - допустим, заказ со статусом в работе может быть только один, если нет ни одного, то нужно создать.
Это чуть сложнее и чуть выше вероятность ошибок, по сравнению со способом отдельной "корзины".

То есть корзина хороша для простого интернет-магазина, предзаказы - для торгово-закупочной деятельности.