Такой вопрос. Как вы считаете где лучше хранить остатки? В таблице товара, в которой десятки полей или отдельно? тоже самое и цены.
Дело в том, что товаров более 100 000. Каждые 10 минут запускается воркер, обновляющий остатки и цены с пересчетом в курсы валют. И как следствие признак "Наличие" товара Да или нет. И получается приходится обновлять эти поля в товере. У товара получается слишком много версий, что накладно хранить в базе.
Сейчас я начал хранить цены в отдельной связанной таблице и обновляю только ее. Сейчас еще планирую остаток вынести тоже в отдельную таблицу и признак available тоже в отдельную. Как считаете правильнее так будет с точки зрения проектирования?
vilinyh, ну ребят, мы же не в 1с находимся)) здесь просто онлайн площадка. в которой товары от разных поставщиков и производителей, которые предоставляют нам ссылку на свою выгрузку. и эту выгрузку мы выкачиваем с определенной периодичностью. Остаток товара меняется в их файлах выгрузки, а так же цена. Партионный учет - это уже их проблема. Наша задача отобразить товар с актуальной розничной ценой и с актуальным остатком (хотя это и невозможно), ведь они сами тоже продают свой товар через другие источники, включая их собственный сайт и может получиться так, что мы получили данные об остатках, у нас заказали товар, а у поставщика уже нет столько товара.
Лучше в отдельных таблицах. Из личной практики скажу, что так лучше для вероятного развития проекта. Например, товар с одним артикулом может находиться на разных складах. Соответственно, остатки и цены могут отличаться для одной и той же номенклатуры.
Вообще хорошим тоном с точки зрения проектирования является отсутствие дубляжа. В данном случае производное из основных данных (остаток как разница поступления и расхода) является дублем.
На такое стоит идти только в угоду реальному повышению производительности.
Собственно расчет свободного остатка - штука быстрая. К примеру даже вычисляемое поле "есть ли свободный запас" при номенклатуре в 1.5 миллиона позиций и в среднем 3-4 уровнях деревьев замен/аналогов "вообще не заметно" в производительности. (MS SQL 4-8 cpu/vcpu 8-16-24 Gb RAM).
С ценами - чуть сложнее - схем ценообразования может быть множество. Поэтому лучше хранить "математику схем" и уже из этого вычислять условно конечную цену. А для нужд бухгалтерского, оперативного, управленческого учетов - вычислять в соответствии с теми нуждами.
дело в том, что мы не ведем учет остатка, потому что он зависит не только от нас. мы просто забираем с определенной периодичностбю остаток с базы данынх поставщика, потому что они тоже продают этот товар и он меняется. А многие (большинство) поставщиков вообще не предоставляют остаток.
У нас есть только одна возможность - обновлять остаток там, где дают с определенной периодичностью +
в момент оформления заказа вытаскивать актуальный остаток, ведь мы не можем в реальном времени его получать. У некоторых 1с включена только в рабочее время и они раз в час шлют нам данные, у других остаток только на сайте есть, но и он тоже не всегда верный, поскольку они продают как с сайта, так и через свой офис и данные синхронизируются не мнговенно. Нам только остается обновлять остаток при первой же возможности. Но отправлять сами нам остаток никто не будет - это технически сложно для них.
Простой
Средний
