On Tue, Dec 2, 2008 at 3:04 PM, MB Software Solutions General Account <[EMAIL PROTECTED]> wrote: > Stephen Russell wrote: >> What I see in that GUI is not the order(s) but the Queue table. >> Right? Or is that a join to Orders that show B.Braun as the customer >> as well as the equipment table for the process as well?. > > > 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?
> 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? 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. >> I see that you only need to do the query one time and include more >> group by data to give the granularity you need. > > No, because that schedule "magnet board" is shown on a big screen in the > production office as well as running on a few different workstations > (for VPs who want to see the active work on the floor and what's in the > treatment queues), the database is requeried quite often perhaps. It's > not just a once and done query...that would have been nice and easy and > thus I would have just relied on the SUM() LEFT JOIN query. Because > it's hit "often" I employed the QTY_IN_QUEUE table with a simple INNER > JOIN. Or perhaps a simple query for the given iOrderID...can't recall > exactly...would have to look back at the code. But I do know that after > I employed this design and a few other optimizations, it was lightning > quick as opposed to before where it was too slow to be useful. Recall > this is a web database that's being polled from a VFP9 rich client app. ----------- No matter how many times it will be called. >> Depending on how much material volume you have, do you need to update >> every min. or every 3? This query should only take a second or two to >> run, it should be all in ram if your running this frequently. > > > 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> -- Stephen Russell Sr. Production Systems Programmer Mimeo.com Memphis TN 901.246-0159 _______________________________________________ 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.
