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

[С.]

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

Ровно также, как сказано вами абзацем выше. Какая цена записана в заказае, по той и считаем.

 

[WMix]

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

реляционная кажись потому что таблицы ... relation == table

 

[Beavis]

реляционная кажись потому что таблицы ... relation == table

http://translate.google.ru/#en/ru/relation

 

[WMix]

Relational term
не всегда нужно знать перевод, иногда нужно знать математику

A relation is defined as a set of tuples that have the same attributes.

 

[panda]

panda


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

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

мне конечно жаль вас разочаровывать

 

[panda]

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

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

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

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

 

[Beavis]

Relational term
не всегда нужно знать перевод, иногда нужно знать математику

A relation is defined as a set of tuples that have the same attributes.

Ну если говорить о математике, то там есть такие понятия как "множество" и "отношение"
"отношение" можно конечно представить в виде таблицы, но, вообще это результат операции над множествами.
Т.е. в результате JOINа 2-х таблиц, получается их отношение.
Поэтому, я считаю, не совсем верно то что table и relation - одно и то же

 

[Вурдалак]

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

Вообще-то отношение на множестве A — это подмножество AxA (если не обобщать). Никаких там результатов операции нет.

 

[Beavis]

а декартово произведение AxB это не операция над множествами A и B?

Никаких там результатов операции нет.

где там? в википедии?))

 

[WMix]

все правильно говоришь

"отношение" можно конечно представить в виде таблицы

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

и в древесной структуре Монго можно организовать джоин, и даже в XQuery это понятие существует и язык похож на SQL, и ссылочность кстати тоже имеется..
но они никаким образом не являются релационными базами!

 

[Beavis]

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

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

 

[Вурдалак]

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

 

[Beavis]

Это не декартого произведение, а его подмножество.

Твои поправки как то влияют на предмет обсуждения? По-моему и так всем понятно о чем речь.

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

Если сначала понять что такое математический объект, то может быть и можно

 

[Вурдалак]

Твои поправки как то влияют на предмет обсуждения? По-моему и так всем понятно о чем речь.

И придраться уже нельзя? Okay.

 

[WMix]

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

 

[Beavis]

Короче каждый о своем.. понятно)
чукча не читатель, чукча писатель