давайте на личности не переходить.

бля

Ну что за двач. Как с такими программистами вообще работать можно?

хватит кормить тролля

стоп плиз...

?

@webwork

Смузихлеб хэх

Друзья, подскажите, пожалуйста Есть таблица orders, где идут основные параметры заказа, т.е. client_id и т.д. Есть таблица products, где хранятся продукты Делаю таблицу order_has_products, где будут храниться данные по товарам из конкретного заказа. Правильно ли я понимаю, для того, чтобы записать текущую цену на продукт в конкретном заказе(она может меняться, само собой), нужно в таблице order_has_products, помимо полей product_id и order_id сделать поле price и discount, чтобы "запоминать" цену на товар в моменте?

Друзья, подскажите, пожалуйста Есть таблица orders, где идут основные параметры заказа, т.е. client_id и т.д. Есть таблица products, где хранятся продукты Делаю таблицу order_has_products, где будут храниться данные по товарам из конкретного заказа. Правильно ли я понимаю, для того, чтобы записать текущую цену на продукт в конкретном заказе(она может меняться, само собой), нужно в таблице order_has_products, помимо полей product_id и order_id сделать поле price и discount, чтобы "запоминать" цену на товар в моменте?

в базе даннных

Друзья, подскажите, пожалуйста Есть таблица orders, где идут основные параметры заказа, т.е. client_id и т.д. Есть таблица products, где хранятся продукты Делаю таблицу order_has_products, где будут храниться данные по товарам из конкретного заказа. Правильно ли я понимаю, для того, чтобы записать текущую цену на продукт в конкретном заказе(она может меняться, само собой), нужно в таблице order_has_products, помимо полей product_id и order_id сделать поле price и discount, чтобы "запоминать" цену на товар в моменте?

Да

Друзья, подскажите, пожалуйста Есть таблица orders, где идут основные параметры заказа, т.е. client_id и т.д. Есть таблица products, где хранятся продукты Делаю таблицу order_has_products, где будут храниться данные по товарам из конкретного заказа. Правильно ли я понимаю, для того, чтобы записать текущую цену на продукт в конкретном заказе(она может меняться, само собой), нужно в таблице order_has_products, помимо полей product_id и order_id сделать поле price и discount, чтобы "запоминать" цену на товар в моменте?

всё так

Друзья, подскажите, пожалуйста Есть таблица orders, где идут основные параметры заказа, т.е. client_id и т.д. Есть таблица products, где хранятся продукты Делаю таблицу order_has_products, где будут храниться данные по товарам из конкретного заказа. Правильно ли я понимаю, для того, чтобы записать текущую цену на продукт в конкретном заказе(она может меняться, само собой), нужно в таблице order_has_products, помимо полей product_id и order_id сделать поле price и discount, чтобы "запоминать" цену на товар в моменте?

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

а можно пойти еще дальше, и вообще не хранить текущее состояние.

а вместо него хранить историю изменений

Что ты имеешь в виду?

Историю изменений в товаре?

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

Историю изменений в товаре?

во всех сущностях

во всех сущностях

Это дороговато и по коду и по базе

Да, очень похоже на оверхед

Хотя может и есть такие задачи

Хотя может и есть такие задачи

Сложно представить в системе хотя бы на 1000 разных товаров

Это дороговато и по коду и по базе

как показывает практика, человеческий мозг сильно уступает профайлеру в точности оценки "дороговатости" таких штук

Хотя может и есть такие задачи

конечно есть. история изменений в тексте статьи

на каких-нибудь например новостных

Хотя может и есть такие задачи

git, например)

это самое первое что приходит в голову

Мы вроде про заказ и продукты говорили

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

Мы вроде про заказ и продукты говорили

история изменения цены и прочего

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

В точку

кто измения вносил, когда и какие

это не всегда оверхед

кто измения вносил, когда и какие

Это уже лог

одно дело лог

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

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

можно, вопрос в том, где это может быть нужно

можно, вопрос в том, где это может быть нужно

ну ты же понимаешь, Жень. оно нужно там, где нужно =)

ну ты же понимаешь, Жень. оно нужно там, где нужно =)

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

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

дык в wp оно же уже прикручено

искаропки

можно, вопрос в том, где это может быть нужно

"Я заказывал у вас стол, на сайте была цена 1000 рублей, а вы мне подсунули за 1300!!! И цену поменяли! Я буду жаловаться!"

только, имхо, то что у них все сущности в одной таблице - это пипец....

"Я заказывал у вас стол, на сайте была цена 1000 рублей, а вы мне подсунули за 1300!!! И цену поменяли! Я буду жаловаться!"

его и история изменений не убедит

"Я заказывал у вас стол, на сайте была цена 1000 рублей, а вы мне подсунули за 1300!!! И цену поменяли! Я буду жаловаться!"

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

а не брать цену каждый раз из текущего состояния сущности

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

ну вот это вот они и прикручивают )

оно правда в вукомерсе есть

ну вот это вот они и прикручивают )

о, я до сути добрался =)

а так не хотелось перечитывать

Хаха

ну дак тут не состояния или история нужны

ERROR: S client not available

тут храни товар в таком виде в котором купили

Блин, ну я это и говорю

ну класс +)

ахаха

пони просто работает в конторе, где проще историю сделать, чем миллионные иски потом огребать

пони просто работает в конторе, где проще историю сделать, чем миллионные иски потом огребать

можно и историю

тогда просто в списке покупок хранить history_id

тогда просто в списке покупок хранить history_id

а скидосы как учитывать?

Ну суть та же

а скидосы как учитывать?

а какие скидосы? я много вариантов-то предложить могу

промокоды, персональные скидки

понятно что акционную скидку на товар - та же хистори айди

промокоды и персональные надо хранить либо в самом order либо держать тоже в строке purchase

промокоды и персональные надо хранить либо в самом order либо держать тоже в строке purchase

?

так более безобидно ^^

?

Суп

двач?

двач?

жареный суп от бати

Парни, спасибо за ответы про копирование объекта товара при заказе в отдельные поля :) Еще самый простой вопрос есть, стоит ли делать денормализацию БД и в каждой строке в orders писать цену? Или лучше просчитывать каждый товар?

Парни, спасибо за ответы про копирование объекта товара при заказе в отдельные поля :) Еще самый простой вопрос есть, стоит ли делать денормализацию БД и в каждой строке в orders писать цену? Или лучше просчитывать каждый товар?

в заказе цены как правило уже неизменны

обычно для пересчёта делают отдельную кнопку

если изменился состав заказа и например есть плюшки за сумму или ещё какие

Странно у вас тут

Ну. Я хранил бы такие вещи как заказ в json, для подсчётов юзал бы вычисляемые поля, и вычисляемые индексы там где нужно

И даже в реляционной модели юзал бы процедуры по факту построения всяких отчётов по заказам