SQL Update - Commit each row in order

Good morning. I'll do my best to explain my question without posting the SQL (it's 650 lines). Let me know if more information is needed.

We have an in-house fulfillment system that is allocating inventory in real time. For allocation to work properly, we need to know how much inventory is available each time a user asks what they should be working on (by loading/reloading their task list). The data would look something like this:

ID    ItemID    QtyOrdered    QtyAvailableAfterAllocation    ParentID
1     1234      5             500                            NULL
2     1234      15            485                            1
3     1234      10            475                            2

Currently a while loop is being used to set the QtyAvailableAfterAllocation column. The example above demonstrates the need for the loop. Row 2's QtyAvailableAfterAllocation is dependent on the value of row 1's QtyAvailableAfterAllocation. Row 3 is dependent on row 2 and so on.

This is the (very) simplified version of the logic. It gets infinitely more complicated when you take into account kits (groups of inventory items that belong to a single parent item). The开发者_开发百科re are times that inventory does not need to be allocated to the item because it exists inside of a kit that has sufficient inventory to fulfill the order. This is why we can't do a running total. Also, kits could be nested inside of kits to the Nth level. Therein lies the problem. When dealing with a large amount of orders that have nested kits, the performance of the query is very poor. I believe that the loop is to blame (testing has proved this). So, here's the question:

Is it possible to commit an update, one row at a time and in a specific order (without a loop), so that the child record(s) below can access the updated column (QtyAvailAfterOrder_AllocationScope) in the parent record?

EDIT

Here is a small portion of the SQL. It's the actual while loop. Maybe this will help show the logic that's needed to determine the allocation for each record.

http://pastebin.com/VM9iasq9

Can you cheat and do something like this?

DECLARE @CurrentCount int
SELECT @CurrentCount = QtyAvailableAfterAllocation 
FROM blah 
WHERE <select the parent of the first row>

UPDATE blah
SET QtyAvailableAfterAllocation = @CurrentCount - QtyOrdered,
    @CurrentCount = @CurrentCount - QtyOrdered
WHERE <it is valid to deduct the count>

This should allow you to keep the update as set based and count downwards from a starting quantity. The crux of the problem here is the WHERE clause.

One method we have been doing is to flatten a hierarchy of values (in your case, the Nth kits idea) into a table, then you can join onto this flat table. The flattening of the hierarchy and the single join should help alleviate some of the performance quirks. Perhaps use a view to flatten the data.

Sorry this isn't a direct answer and only ideas.

If you can provide a sample data structure showing how the kits fit in, I'm sure someone can help thrash out a more specific solution.

If you do have requests queued up in some structure, you wouldn't employ a SQL statement to process the queue; "queue" and "SQL", conceptually, are at odds: SQL is set-based, not procedural.

So, forget about using a query to manage the queued requests, and process the queue in a procedure, wrapping each part requisition in a transaction:

        pseudo:
        WHILE REQUESTS_REMAIN_IN_QUEUE

             begin trans
                execute requisition SQL statements
             commit

        LOOP

Your requisition statements (simplified) might look like this:

           update inventory
           set QOH = QOH- {requested amount}
           where  partno = ? and QOH >= {requested amount}

           insert orderdetail
           (customer, orderheaderid, partno, requestedamount)
           values
           (custid, orderheaderid, partno, requested_amount)

Now in a complicated system involving kits and custom business logic, you might have a rule that says not to decrement inventory if every component in a kit is not avaialable. Then you'd have to wrap your kit requisition in a transaction and rollback if you encounter a situation where an individual component in the kit is backordered, say.

I think this problem can be solved using purely set-based approach.

Basically, you need to perform these steps:

1. Obtain the table of currently available quantity for every item.

2. Obtain the running totals from the ordered quantity due to be processed.

3. Get QtyAvailableAfterAllocation for every item as the result of subtraction of its running total from its available quantity.

Here's a sample solution:

/* sample data definition & initialisation */
DECLARE @LastQty TABLE (Item int, Qty int);
INSERT INTO @LastQty (Item, Qty) 
  SELECT 0123, 404 UNION ALL
  SELECT 1234, 505 UNION ALL
  SELECT 2345, 606 UNION ALL
  SELECT 3456, 707 UNION ALL
  SELECT 4567, 808 UNION ALL
  SELECT 5678, 909;
DECLARE @Orders TABLE (ID int, Item int, OrderedQty int);
INSERT INTO @Orders (ID, Item, OrderedQty)
  SELECT 1, 1234,  5 UNION ALL
  SELECT 2, 1234, 15 UNION ALL
  SELECT 3, 2345,  3 UNION ALL
  SELECT 4, 1234, 10 UNION ALL
  SELECT 5, 2345, 37 UNION ALL
  SELECT 6, 2345, 45 UNION ALL
  SELECT 7, 3456, 50 UNION ALL
  SELECT 8, 4567, 25 UNION ALL
  SELECT 9, 2345, 30;

/* the actuall query begins here */
WITH RankedOrders AS (
  SELECT
    *,
    rn = ROW_NUMBER() OVER (PARTITION BY Item ORDER BY ID)
  FROM @Orders
),
RunningOrderTotals AS (
  SELECT
    ID,
    Item,
    OrderedQty,
    RunningTotalQty = OrderedQty,
    rn
  FROM RankedOrders
  WHERE rn = 1
  UNION ALL
  SELECT
    o.ID,
    o.Item,
    o.OrderedQty,
    RunningTotalQty = r.RunningTotalQty + o.OrderedQty,
    o.rn
  FROM RankedOrders o
    INNER JOIN RunningOrderTotals r ON o.Item = r.Item AND o.rn = r.rn + 1
)
SELECT
  t.ID,
  t.Item,
  t.OrderedQty,
  QtyAvailableAfterAllocation = oh.Qty - t.RunningTotalQty
FROM RunningOrderTotals t
  INNER JOIN @LastQty oh ON t.Item = oh.Item
ORDER BY t.ID;

Note: For the purpose of my example I initialised the available item quantity table (@LastQty) manually. However, you are most probably going to derive it from your data.

Based on the comments/answers above and my inability to accurately represent this complicated issue properly, I've rewritten the processing in C#. Using PLINQ, I've reduced the processing time from 15 seconds to 4. Thanks to all those who tried to help!

If this isn't the appropriate way to close a question, let me know (and let me know the appropriate way so I can do that instead).