Как лучше базу пользовательских заказов организовать?

[Filin]

Как лучше базу пользовательских заказов организовать?

Допустим есть на сайте пользователи(таблица пользователей) которые делают покупки, они могут купить какоето количество товаров за раз и вернутся когда нибудь совершить еще покупку, в базе данных надо хранить закрепленные заказы за пользователем и их содержимое.
Вопрос как это организовать: для каждого пользователя создавать по отдельной таблице его покупок? или все заказы грузить в одну таблицу?
ПС: а какое количество таблиц можно создавать в MySql?

 

[Sad Spirit]

Автор оригинала: Filin
Вопрос как это организовать: для каждого пользователя создавать по отдельной таблице его покупок? или все заказы грузить в одну таблицу?

Лучше по одной таблице на заказ.

ПС: а какое количество таблиц можно создавать в MySql?

Вот заодно и выяснишь, хе-хе.

 

[maxim]

вот пример с двумя таблицами
table orders

order_id | user_id | total_sum| status | date_time


table order_item

order_id | prod_id

 

[Filin]

Автор оригинала: maxim
вот пример с двумя таблицами
table orders

order_id | user_id | total_sum| status | date_time


table order_item

order_id | prod_id

К сожалению таблица вида order_item мне не подойдет, товаров разных по типу не много, но каждый товар имеет особые параметры такие как материал, размер(может быть любым) от которых зависит цена изделия. Так что я мог бы отделатся с помощью prod_id только если напишу функцию которая будет ставить этот prod_id в соответствие набору параметров

 

[Marquis]

Вот заодно и выяснишь, хе-хе.

"эта пять"

 

[maxim]

Ну да а в product есть поля - размер, вес, цвет и тд.
Вот и делай запрос по трем таблицам.

 

[Filin]

Автор оригинала: maxim
Ну да а в product есть поля - размер, вес, цвет и тд.
Вот и делай запрос по трем таблицам.

Нет, размера там нет, его вводит пользователь.
Буду делать таблицу заказов и валить туда все заказы с описаниями товаров.
По повуду количества таблиц, узнал что оно зависит от количества записей в таблицах.