Форум PHP

Добрый день.
Расскажите плиз, как лучше хранить заказы пользователя. И как быть с тем, что пользователь может заказать сразу несколько товаров в одном заказе?
Например я себе представляю это так:
В табличке orders хранить заказ, в котором есть столбцы userid, addtime, summa, tovar
В столбце tovar хранить массивом ID товара и кол-во заказываемых штук.
Например:

<?php $tov = array("15;1", "14;5" и т.д.); ?>

Например, пользователь в одном заказе купил четыре книжки, каждую по три экземпляра.
Как все упростить, чтобы потом удобно обрабатывать эти заказы?
Подкажите кто с этим с талкивался, заранее благодарен за Ваши идеи.

Лучше так:
1. Таблица заказов, в нее входят поля: номер заказа (уникальный, автоинкремент), данные о заказчике (ФИО, адрес, e-mail и прочее), дата заказа.
2. Таблица товаров заказа, которая содержит поля: номер заказа, id заказанного товара, название товара, цена товара, количество заказанного товара. Каждая запись этой таблицы (товар) связана по номеру заказа с первой таблицей.

Я делал немного иначе. Мой способ не претендует на звание "лучший и оптимальный", но зато он железно работает.
Как только покупатель кидаетт в корзину первый товар, автоматом генерится таблица в БД с именем `basket_$ID`, где $ID - это идентификатор данного пользователя. В таблице каждая новая строчка - это "id,название, цена и др." товара, который покупатель кладет в корзину. Таким образом, как только пользователь доходит до страница оформления покупки - в его корзине (таблице) есть товары (допустим 3-5 штук). На странице оформления покупки можно удобно отобразить все его содержимое корзины (тупо из таблицы), разрешить удалить ненужные покупки (если надо ему) и т.д. А потом, как только покупатель нажмет кнопку "оформить" - все его товары переносятся в в постоянную таблцу всех заказов. И только когда сессия пользователя завершиться (не важно каким путем) - его временная таблица (корзина) автоматом убивается, дабы не засорять БД.
Результат - LinuxMarket.ru

>И только когда сессия пользователя завершиться (не важно каким путем) - его временная таблица (корзина) автоматом убивается, дабы не засорять БД.

И что это за автомат такой?

АК-74

Юмор? Ценю.
А по существу?

Потому Калашников и вспомнился, так как: - "таблица (корзина) автоматом убивается" выглядит "как само собой разумеющееся".

в том то и дело, что убивать её скорее всего придется в лучшем случае ножом.

Юмор? Ценю.

в данном случае "автоматом" - имеется ввиду, что скрипт убивает временную таблицу по завершению сессии. (например после нажатия на "Выход", а еще CRON может помочь :) )

Вот именно.
Полагаться на то, что посетитель не забудет найти и нажать соответствующую кнопку - явно обозначить завершение сеанса, не приходится.
Значит таблица будет репыхаться либо до реакции cron'а либо (что где-то как-то проще) до срабатывания ветви проверки на время устаревания в основном скрипте. В любом случае скрипту придется предпринимать явные действия по удалению таблицы.
Если уж на то пошло, способ с единой таблицей на все временные заказы ничуть не хуже. И даже безопасней. Как минимум привилегии на исполнение Data Definition Statements ему не требуются. Да и удаление устаревших строк там можно выполнить за одно обращение к серверу. С удалением таблиц одним махом так красиво не выйдет.

С тем же успехом можно просто сессию применить, а при оформлении заказа, переписать данные в таблицу заказов. Таблицу для неоформленных заказов оправдано делать, когда в магазине есть клиенты, и они могут отложить заказ, оформлять часть своего заказа и т.п., мне так кажется.