в каком месте кода сериализовать данные

[Redjik]

например?

 

[Jon]

например?

Ну скажем
1. таблица городов
2. таблица транспортных компаний
3. связь город-транспортная компания (где есть ID)

И в один прекрасный момент мне нужно показать пользователю все возможные варианты по городу, после чего записать это в новую "таблицу 4"

 

[Baton]

В таблице связей, тоже бывает полезно завести поле ID. Удалять легче, а точнее передавать с клиента надо только один ID этой связи, а не несколько item1ID, item2ID,.. itemNID, ну и в коде клиента все становится легче. На сервере проверить легче один (int)$ID. Кароче из личного опыта пришел к выводу об удобстве заведения идентификатора связи.

Но признаю, что можно и обойтись. Дело вкуса, стиля.

 

[panda]

всем большое спасибо за вариант организации бд.

Правильно ли я понимаю, алгоритм, т.е есть таблица product(id_product), есть таблица order (id_order), есть таблица связка product-order(id_pr-or), Quantity по каждому продукту

1) Заходит user, нажимает зделать заказ, фомируем таблицу order (id_order), data и т.д
2) видит список продуктов, проставляет к-во, нажимает отправить, ключи (id_order) и (id_product) сохраняются в product-order(id_pr-or)

а если он передумает на шаге 1)??? не станет продолжать, как вычистить таблицу order (id_order) - заказа же не будет

 

[baev]

Правильно ли я понимаю, алгоритм, т.е есть таблица product(id_product), есть таблица order (id_order), есть таблица связка product-order(id_pr-or), Quantity по каждому продукту

1) Заходит user, нажимает зделать заказ, фомируем таблицу order (id_order), data и т.д
2) видит список продуктов, проставляет к-во, нажимает отправить, ключи (id_order) и (id_product) сохраняются в product-order(id_pr-or)

а если он передумает на шаге 1)??? не станет продолжать, как вычистить таблицу order (id_order) - заказа же не будет

1. Алгоритм Вы поняли неправильно. Что мешает писать id_order в базу после окончательного оформления заказа?
2. Даже если следовать Вашему алгоритму: что мешает «вычистить» id_order?

Вообще, жесть, конечно.
По-моему, с такими знаниями рано браться за «электронную коммерцию»…

 

[Linker]

Panda:

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

 

[panda]

Panda:

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

такой вариант возможен , т.е (вставлять запись в таблицу order только после того, как есть хотя бы одна позиция для таблицы product-order), но у меня немного другая специфика и так сделать будет не разумно


у меня: приходит пользователь, постоянный !!! смотрит в своем личном кабинете - свои накладные , еще какую то инфу для него предназначенную, потом собирается оформлять заказ, видит спсок продуктов, заполняет к-ва и потом заказ должен быть сохранен. Это не логично после того как он заполнит ко-ва формировать таблицу order. Как думаете???? Как быть

 

[Фанат]

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

 

[panda]

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

неудобный вариант с тремя таблицами

еще раз

таблица 1) прайс с ценами
таблица 2) заказ с датазаказа, юзер и id заказа
таблица 3) прайс+заказ связка


заказ один и тот же пользователь делает 2 раза в нелделю. в таблицу 3) предется все из таблицы 1) перетаскивать + добалять к-во, одними ключами неотделаться, потому как заказы нужну хранить за год а прайс - таблица 1) меняется каждый день, и мало того в прайсе просто может нестать того продукта, который юзер заказывал неделю назад.


Вопрос имеет ли смысл такая архитектура бд и не лучше ли сериализовать заказ в строку и хранить так???

 

[С.]

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

 

[Linker]

panda
я так понимаю, вы замахнулись на задачу весьма нетривиальную, а опыта у вас совсем нет в такого рода делах...
мне снова бросилось в глаза упоминание о "прайс-листе" из которого я понял, что у вас нет чёткого представления о том, как это будет выглядеть на практике, насколько я понимаю, "прайс-лист" это опять же - не одна таблица. Вот к примеру, у вас на один и тот же товар меняется цена, вы же не собираетесь удалять старую цену и вставлять на её место новую? Где потом брать старую? И вообще, это весьма и весьма обширная область (архитектура базы данных) проектированием сложных систем занимаются отдельно, поэтапно, в интернете много информации на эту тему, вы бы для начала максимально подробно изучили бы эту область. Реализация на PHP + MYSQL это, поверьте, уже менее сложный вопрос, в отличии от проектирования самой базы данных.

 

[WMix]

невижу ничего страшного, если информацию о продукте и о пользователе продублировать в заказ.
резон? правильно сказанно продукт может измениться, просто вчера продавали по 10 сегодня по 11, у клиента поменялся адрес и тд
при этом в заказе ничего НИВКОЕМ СЛУЧАЕ не должно измениться

можно можно сериализировать, но про статистику, удобный пойск заказов по регионам, по ценам, по ... забудте...
а если уже сериализировать может стоит подумать о документ базираванных данных тип монго?
оно вроде и джейсон и вроде строка!

 

[panda]

panda
я так понимаю, вы замахнулись на задачу весьма нетривиальную, а опыта у вас совсем нет в такого рода делах...
мне снова бросилось в глаза упоминание о "прайс-листе" из которого я понял, что у вас нет чёткого представления о том, как это будет выглядеть на практике, насколько я понимаю, "прайс-лист" это опять же - не одна таблица. Вот к примеру, у вас на один и тот же товар меняется цена, вы же не собираетесь удалять старую цену и вставлять на её место новую? Где потом брать старую? И вообще, это весьма и весьма обширная область (архитектура базы данных) проектированием сложных систем занимаются отдельно, поэтапно, в интернете много информации на эту тему, вы бы для начала максимально подробно изучили бы эту область. Реализация на PHP + MYSQL это, поверьте, уже менее сложный вопрос, в отличии от проектирования самой базы данных.

спасибо я конечно читаю информацию и в нете и в книжицах, но хочется еще обсуждать


у меня такая специфика, продукт аукционный, поэтому цены меняются каждый день на него. и кроме того сам продукт, т.е его наличие не всегда доступно например в июле есть в августе нет, и также появляются раз в месяц новые продукты. И я считаю ничего с этим прайсом поделать нельзя кроме как сидеть и каждый день вносить изменения.

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


Сейчас это все делается руками в эксели, и это стало занимать много времени, хоетлось как то сделать виртуально

 

[panda]

иметь возможность потом получить статистику по отдельным продуктам это конечно классно, но все же не так актуально, главное сохранять историю заказов,


для покупателей иметь возможность видеть общую цену заказа, сам заказ, цены по продуктам

 

[panda]

невижу ничего страшного, если информацию о продукте и о пользователе продублировать в заказ.
резон? правильно сказанно продукт может измениться, просто вчера продавали по 10 сегодня по 11, у клиента поменялся адрес и тд
при этом в заказе ничего НИВКОЕМ СЛУЧАЕ не должно измениться

можно можно сериализировать, но про статистику, удобный пойск заказов по регионам, по ценам, по ... забудте...
а если уже сериализировать может стоит подумать о документ базираванных данных тип монго?
оно вроде и джейсон и вроде строка!

ой это я не слышала ни разу , -----

о документ базираванных данных тип монго?
оно вроде и джейсон и вроде строка!

 

[panda]

Вот к примеру, у вас на один и тот же товар меняется цена, вы же не собираетесь удалять старую цену и вставлять на её место новую? Где потом брать старую?

а какой вариант именно так и собираюсь просто редактировать, нет другого варианта! Видите как иначе подскажите.


я не могу хранить цены каждого дня, мне кажется мне это не нужно, мне выгодно хранить заказы с ценами на ту или иную дату, а прайс все время менять

 

[WMix]

если меняются продукты и нужна история, простой способ (немножко грязно, обьяснения ниже) написать триггер на изменения таблицы прайсов, который будет пихать изменения в историю прайсов с актуальной датой..
красиво написать конечно на пыхапы, но тогда и изменения делать ТОЛЬКО на пыхапы..

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

или интересно mongodb bzw couchdb или все базы под флагом NoSQL
когда одна строка в базе это некое дерево аттрибутов
{
order_id: xyz
customer: { firstname: aaa, lastname:bbb ... }
items: [ { product_nr: xxxyyyzzz, price: 123 ...}, {} ...]
...
}

и можно сделать запрос тип, покажи все заказы где product_nr = xxxyyyzzz

 

[WMix]

иметь возможность потом получить статистику по отдельным продуктам это конечно классно,

имелов в виду статистику не по изменениям цен, а статистику по продажам..
как мы продавали продукты, как изменилась продажа когда цена упала...

 

[Linker]

panda

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

нет тут никакой специфики, это нормально, когда меняются цены (да хоть каждый час, да хоть ежеминутно),
товар везде и всегда может быть в наличии, а может и не быть, это не новость, не особенность и не специфика никакая...
и ясный перец, товары могут появляться новые (а если кто торгует только старыми и всегда одними и теми же, то тогда это и будет "специфика")
всё, кончилась специфика? Ах, да, ещё "особые клиенты" некий круг избранных:

(земетим не случайно зашедшие люди, а регулярно испльзующие этот прайс)

из этого, конечно следует, что реляционная база данных, названная так именно благодаря связям между таблицами, нас уже не интересует, точнее, её можно использовать, но чтобы это было не сложнее чем в Excel'e табличку руками отредактировать, а если сложнее, то надо тогда как-то "упростить" как-то "сериализовать", а то три таблицы это неудобно (wtf?)
Эх, panda, а мне-то вначале показалось, что вам действительно хотелось разобраться или сделать что-то толковое самостоятельно...
Выходит baev прав, как всегда.

 

[Adelf]

panda
к тому что вам посоветовали можно добавить новое поле. Например, цена товара на момент заказа. И проблема будет решена(вроде). Ну вы вроде и сами уже догадались.

Вопрос остальным - а как вы реализовывали хранение заказов. Если клиент заказал продукт по одной цене.. в течении обработки заказа у вас цена поменялась. Как у вас обрабатываются такие ситуации?

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