Le Thu, 26 Jan 2012 11:28:21 +0100, Cédric Krier <[email protected]> a écrit :
> On 25/01/12 14:43 +0100, Bertrand Chenal wrote: > > Le Wed, 25 Jan 2012 13:45:25 +0100, > > Cédric Krier <[email protected]> a écrit : > > > Also I think such behavior will be very resource consuming. > > > > I'm not sure but I think it's just a matter of changing > > > > GROUP BY to_location, product > > > > to > > > > GROUP BY to_location, product, lot > > > > in the products_by_location method, except that it must be done > > through inheritance. > > Indeed it will be ressource consuming because the stock period works > at product level and not at lot. > And I don't think caching per lot is a smart design choise, the number > of row in such table will increase very fast. > I agree that caching per location and per lot is not a good idea. So, new proposal: a naive product_by_lot function will be slow, so we need caching. As lots are a bit like temporary locations, caching per period makes no sense. But we can flag 'empty' lots, I.E. lots for which all products have been sent to customers (or consumed by a production). While the number of lot gets bigger and bigger as the time goes, the number of non-empty lot will stay nearly stable. This means that an efficient product_by_lot is doable: we only have to consider the moves that are linked to an non-empty lot. And for the same price we can do a "product_and_location_by_lot". Now, the question of how to integrate this with shipments and assignment will depends of the use case. -- Bertrand Chenal B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email: [email protected] Website: http://www.b2ck.com/ -- [email protected] mailing list
