| Author |
 Topic  |
|
|
swissivan
Starting Member
29 Posts |
 Posted - 02/18/2013 : 22:00:46
|
I got an table for storing transaction of stock in and out
simplified as follow
seq | date | stockid | type | qty
1 | 2013-02-10 | aaa | in | 10
2 | 2013-02-11 | bbb | in | 20
3 | 2013-02-13 | aaa | out | 3
...
I would like to got the stock balance at certain time
e.g. stock balance at 2013-02-13, aaa = 7 and bbb = 20
However I do concern on the performance after two year
e.g. if I start this system on 2013-01-01, there will be a lot of transaction when lookup at 2014-12-31
Calculate 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. |
Edited by - swissivan on 02/18/2013 22:01:39
|
|
|
visakh16
Very Important crosS Applying yaK Herder
India
47189 Posts |
Posted - 02/19/2013 : 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 here
http://www.brentozar.com/sql/table-partitioning-resources/
------------------------------------------------------------------------------------------------------
SQL Server MVP
http://visakhm.blogspot.com/
|
 |
|
|
swissivan
Starting Member
29 Posts |
|
|
visakh16
Very Important crosS Applying yaK Herder
India
47189 Posts |
Posted - 02/20/2013 : 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 here
http://www.brentozar.com/sql/table-partitioning-resources/
------------------------------------------------------------------------------------------------------
SQL Server MVP
http://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 partitioning
You just need to have enterprise edition for sql server
------------------------------------------------------------------------------------------------------
SQL Server MVP
http://visakhm.blogspot.com/
|
|
|
|
swissivan
Starting Member
29 Posts |
Posted - 02/20/2013 : 03:56:11
|
| Thank you again. I will have more research on this. |
|
|
|
James K
Flowing Fount of Yak Knowledge
1530 Posts |
Posted - 02/20/2013 : 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
Yak Posting Veteran
USA
79 Posts |
Posted - 02/20/2013 : 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
Yak Posting Veteran
USA
79 Posts |
Posted - 02/20/2013 : 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. |
|
|
| |
Topic |
|
Any Good Pratice for Stock Transaction Table
