Not if we are still talking about Oracle.

I will have to add some kind of “comment preview” functionality to the site.

Thanks.

Tim,

The underlying problem here probably is that the performance in scanning a table of inventory transactions to calculate the balance is poor, so here’s some thoughts on that.

Firstly, I like the MV idea. There’s a certain risk in adopting it because you are potentially using code paths in the RDBMS that you haven’t used before, so your exposure to bugs in the Oracle code is higher. You might have trouble if you need to archive old transactions.

Secondly, if you want to calculate balances for a particular item based on inventory transactions then clustering the transactions together would be one option. Putting the table into a hash cluster based on the item identifier would do this nicely — again, new code paths being used.

Thirdly, you could adopt a hybrid strategy of calculating balances based on an intermittently-maintained balance table and a subset of your transactions … you might define the balance table as …

ITEM#
AS_OF_DATE
BALANCE_QTY

.. and populate it as …

SELECT
   ITEM#,
   MAX(TRANSACTION_DATE),
   SUM(BALANCE_CHANGE_QTY)
FROM
   INVENTORY_TRANSACTIONS
GROUP BY
   ITEM#

You’d maybe want to update the balance table at 3am using a predicate such as …

TRANSACTION_DATE

… and then calculate the current balance based on a query like …

SELECT
   ITEM#,
   BALANCE_QTY+
   (SELECT SUM(BALANCE_CHANGE_QTY)
    FROM   INVENTORY_TRANSACTIONS IT
    WHERE  IT.ITEM# = IB.ITEM# AND
           TRANSACTION_DATE > IB.AS_OF_DATE)
FROM
   INVENTORY_BALANCE IB
WHERE
   ITEM# = 12345

This would allow you to archive inventory transactions, or reduce the amount of work required to calculate the balance dynamically if you had a very high number of transactions and you could efficiently query a subset of them by ITEM# and semi-bounded range of TRANSACTION_DATE.

This third strategy also extends to allowing manual adjustments to the inventory balance in another table — the world being what it is one often finds that balances are not what they should be.

I also have a better understanding as to what types of questions are appropriate for this site as well.

-Tim

you might like to see if you can put a warning on the “Ask a new question” page to warn against specific question
Great suggestion. The About page answers exactly what type of questions and answers should be submitted, however, I will look into adding such warning on the “new post” page as well.

But I answered your question. Just use a plain view with the group by. You can then use it in all of your other SQL. It’s not an inline or materialized.

Do you know what you’re doing? I think you are over complicating a simple task.

The table is there, just make a view using a group by. Simple enough. No Meterialized needed unless you end up with a huge table. To keep the table small I would do this perhaps.

DROP TABLE t_inventory_temp;

CREATE TABLE t_inventory_temp
AS SELECT * from t_inventory;

DELETE FROM t_inventory;

INSERT INTO t_inventory
SELECT product_id, sum(in_stock)
FROM t_inventory_temp;

(I would not drop t_inventory_temp as it could also be a temporary backup location. Nice to have for troubleshooting purposes etc.)

You’re done. Maybe reindex here?

That’s pretty simple and keeps the table small.

If it was up to me I’d delete the question and redirect the OP to a forum — you might like to see if you can put a warning on the “Ask a new question” page to warn against specific question (or is there already one?), similar in purpose to the “Fair Warning” on AskTom.

I’ll further my original post with more details to hopefully make it clear what I’m doing.

1. My “in stock” table is named t_inventory (product_id, in_stock)
2. I can see the current “in stock” by selecting a single row from this table by using it’s product_id.
3. t_inventory has an index on product_id
4. When a transaction that affects “in stock” is committed I place a row in t_inventory_queue (product_id, in_stock_change), which contains the product_id and the amount to increment or decrement “in stock”
5. I have a job in my database that runs every minute and takes the changes from t_inventory_queue and updates (or inserts) rows in t_inventory, it then deletes the row from t_inventory_queue.

The benefit of the t_inventory approach (instead of doing a select sum() with a group by) is that in much of my application I can include t_inventory right in my SQL FROM clauses, instead of having to do inline views or call stored functions, since I’ll only have a single row for any product_id.

As I mentioned before, the two downsides are:

1. The DBA drops the job, the job breaks (it could but I’ve never seen it happen in my schema) or the job never runs or runs too infrequently (job_queue_interval and job_queue_processes).

2. With the job running every 60 seconds the worst case scenario is that others won’t see the true “in stock” values for up to a minute.

One of my thoughts was to run the job more frequently (every 15 seconds). I know that in Oracle8i you have access to job_queue_interval but that isn’t available any more in 9i. Does anyone know how often the job queue is checked in 9i and above?

I’ve read just a little about advanced queues, I’m not sure if that is appropriate or not. It seems to me that if the “job” I’m currently running could be run immediately if there are rows committed to t_inventory_queue that would be ideal. The key is that only a single process ever processes rows from t_inventory_queue (something Oracle’s job functionality does for me right now).

-Tim