Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2008 Forums
 Transact-SQL (2008)
 Any Good Pratice for Stock Transaction Table

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 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.

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 here

http://www.brentozar.com/sql/table-partitioning-resources/

------------------------------------------------------------------------------------------------------
SQL Server MVP
http://visakhm.blogspot.com/

Go to Top of Page

swissivan
Starting Member

30 Posts

Posted - 2013-02-19 : 20:20:29
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?
Go to Top of Page

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 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/

Go to Top of Page

swissivan
Starting Member

30 Posts

Posted - 2013-02-20 : 03:56:11
Thank you again. I will have more research on this.
Go to Top of Page

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.
Go to Top of Page

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.

Go to Top of Page

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.
Go to Top of Page
   

- Advertisement -