Hi folks.I know you'll say "you have to experiment it" but I need your opinions. Here are key points of project:its credit card transaction project. Meaning once record inserted its never updated.there are 1 million existing records. there will be maybe 5 transaction every second.As its credit card project I need to track transaction volumes for each customer.it means I need to run SUM statement every time. It must be rely on real data.Of course it causes deadlocks and takes too much time.so I wrote stored procedure for this one big table. It consider delete, insert and update situations andadds INSERTED.amount or DELETED.amount to summary table.but it adds/subtracts multiple records.one for customer, one for bank, 2 for chargebacks, 2 for refunds... basically it inserts/updates almost 20 records. for every year/month there are these 20 record block.Each record is for some variable. [code="other"]Year Month CustomerID Type Value------------------------------------------------2015 1 10 Refund_Count 52015 1 10 Refund_Amount 2002015 2 10 Refund_Count 32015 2 10 Refund_Amount 120..................[/code] It works perfectly but last week I started to look into indexed views.These stored procedure functionality can be achieved using 20 different indexed views.And I need to combine all these queries with UNION ALL In code, I can arrange the rest. no problem for me.my question is:As index views keeps a separate physical data it means it gets data from source and writes to database.for 20 different indexed views it must write something 20 times.my SP also does the same thing.Logic says there's no difference.Both solution wont cause deadlocks and as they query small separate table they are both fast.Because I don't use SUM anymore, I only query a field.Would you get rid of SPs and replace them with indexed views ?Or would you say "there will be no performance difference so leave it as it is"or would you say "in future .... kind of problem can be faced so use ...."do you have suggestions based on experiences ?best.
↧