On 26/01/12 13:10 +0100, Bertrand Chenal wrote: > 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,
If so, why not use location instead of lot? > 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. -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgpOrBqgs5ZaR.pgp
Description: PGP signature
