Stephen Russell wrote: > On Tue, Dec 2, 2008 at 3:04 PM, MB Software Solutions General Account > <[EMAIL PROTECTED]> wrote: >> No, that's NOT the queue...that's the Orders to be nailed. They get >> sent to the queue AFTER they're nailed. >> > --------------------------------- > How do you evaluate that there is no treatment on this order then?
If the Orders.cTreatCode is empty, no treatment is needed. If it's H, then it gets Heat treatment; if it's D, then it gets Dip treatment, etc. > > >> There's no status column (nor do I want that). You've got the ordered >> qty (e.g., 1000), and then they send off portions of that qty to the >> queue as they're nailed. So you'll have perhaps 3 bundles of >> 300,400,300 sent to the treatment area. The status would be either in >> nailing, some sent to queue, and then all qty sent to queue. What's >> important is not the status but just the OrderedQty vs. TreatedQty. And >> some orders don't get treatment, btw. > ----------------------------------------------------------- > > How many transactions are in the queue table anyway? A few hundred or > a hundred thousand in a years time? Well, in looking at their data, it appears that they're not having the amounts of data I expected....they've had 1500 in the past year. That is a small number, and I suppose I could justify the SUM() using the LEFT JOIN instead of relying on the QTY_IN_QUEUE table, but my concern with that would be the additional testing and possible decline in performance to replace what's already working with something else. However, if the QTY_IN_QUEUE table continues to crash even after switching to InnoDB, I'll go back to that approach certainly. > > I see 3 rows in your example above right? As they are created are > they set in a status of awaiting treatment and that can be changed as > the treatment occurs? > > Or will there be a finer gauge 300 in and they update the count as it happens? > > I guess a schema would help at this point. http://mbsoftwaresolutions.com/downloads/remmey/scheduler/schema20081202.html >> It's not in RAM because it's a MySQL database on the web. If it were >> Foxpro data, yes, you'd be right that it'd be in RAM. I think they've >> got their updates/requeries set to run every 1-3 minutes, depending on >> the user's preference set as his workstation. > --------- > > On the data server those tables will be in RAM instead of having to be > read from disk. This will happen because the volume of times the > query will run per hour. <many per min probably> Hmmm...maybe. _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
