Author |
Topic |
swissivan
Starting Member
30 Posts |
Posted - 2013-02-18 : 22:00:46
|
I got an table for storing transaction of stock in and outsimplified as followseq | date | stockid | type | qty1 | 2013-02-10 | aaa | in | 102 | 2013-02-11 | bbb | in | 203 | 2013-02-13 | aaa | out | 3...I would like to got the stock balance at certain timee.g. stock balance at 2013-02-13, aaa = 7 and bbb = 20However I do concern on the performance after two yeare.g. if I start this system on 2013-01-01, there will be a lot of transaction when lookup at 2014-12-31Calculate stock balance will take times to sum up a lot of transactions (all transactions from 2013-01-01 to 2014-12-31)Any suggestion on this situation? thanks. |
|
visakh16
Very Important crosS Applying yaK Herder
52326 Posts |
Posted - 2013-02-19 : 00:05:52
|
If you want to capture day wise details this is way you need to implement. For better performance what you can do is to do partitioning of table based on date field. Create partition for convenient period (month,quarter etc) and keep partition onto different file groups.See more details herehttp://www.brentozar.com/sql/table-partitioning-resources/------------------------------------------------------------------------------------------------------SQL Server MVPhttp://visakhm.blogspot.com/ |
|
|
swissivan
Starting Member
30 Posts |
|
visakh16
Very Important crosS Applying yaK Herder
52326 Posts |
Posted - 2013-02-20 : 01:25:42
|
quote: Originally posted by swissivan
quote: Originally posted by visakh16 If you want to capture day wise details this is way you need to implement. For better performance what you can do is to do partitioning of table based on date field. Create partition for convenient period (month,quarter etc) and keep partition onto different file groups.See more details herehttp://www.brentozar.com/sql/table-partitioning-resources/------------------------------------------------------------------------------------------------------SQL Server MVPhttp://visakhm.blogspot.com/
Thanks for your reply.As stated from the following, there is a license for commercial use so it is not a solution for me.http://www.brentozar.com/archive/2012/03/how-decide-if-should-use-table-partitioning/Any other no cost suggestion?
no special license just for table partitioningYou just need to have enterprise edition for sql server------------------------------------------------------------------------------------------------------SQL Server MVPhttp://visakhm.blogspot.com/ |
|
|
swissivan
Starting Member
30 Posts |
Posted - 2013-02-20 : 03:56:11
|
Thank you again. I will have more research on this. |
|
|
James K
Master Smack Fu Yak Hacker
3873 Posts |
Posted - 2013-02-20 : 07:55:14
|
If you are allowed to create tables in your database, I would suggest that you create an end-of-day (EOD) positions table, precompute the EOD positions and store in that table. Usually security transactions settle within at most 3 business days, and any cancel/corrects within a few days thereafter. So you could pre-compute the positions from inception to T-10 or so and store in that table. Then you can query against that table which would be fast.This is a standard problem in the financial industry. I have seen commercial order management systems that use both approaches - i.e., storing positions and computing positions on the fly. The perennial problem that the latter kind runs into, as you found out, is performance related. So even they aggregate the trades and store EOD positions periodically (at the end of each month or at the end of each week etc.) and use those positions as starting point for computing positions during the month/week. |
|
|
ScottPletcher
Aged Yak Warrior
550 Posts |
Posted - 2013-02-20 : 17:40:07
|
You likely won't need to partition, and certainly not starting out.But you do need to cluster that table first by datetime (NOT by an identity column).Whether or not you should include the stock symbol as a second clustering key would depend on how you query the table. |
|
|
ScottPletcher
Aged Yak Warrior
550 Posts |
Posted - 2013-02-20 : 17:42:56
|
quote: Calculate stock balance will take times to sum up a lot of transactions (all transactions from 2013-01-01 to 2014-12-31)
You can precompute stock balances for every day as soon as that day is over, and store them in a separate table (again, clustered first by date). If for some reason you add/change stock transactions before the current date, then naturlly you will have to recompute any affected totals. Hopefully that would be very rare, or even never. |
|
|
|