SQL Server Forums
Profile | Register | Active Topics | Members | Search | Forum FAQ
 
Register Now and get your question answered!
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 SQL Server 2008 Forums
 Transact-SQL (2008)
 Any Good Pratice for Stock Transaction Table
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

swissivan
Starting Member

30 Posts

Posted - 02/18/2013 :  22:00:46  Show Profile  Reply with Quote
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
52249 Posts

Posted - 02/19/2013 :  00:05:52  Show Profile  Reply with Quote
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 - 02/19/2013 :  20:20:29  Show Profile  Reply with Quote
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

India
52249 Posts

Posted - 02/20/2013 :  01:25:42  Show Profile  Reply with Quote
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 - 02/20/2013 :  03:56:11  Show Profile  Reply with Quote
Thank you again. I will have more research on this.
Go to Top of Page

James K
Flowing Fount of Yak Knowledge

3334 Posts

Posted - 02/20/2013 :  07:55:14  Show Profile  Reply with Quote
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
Constraint Violating Yak Guru

USA
279 Posts

Posted - 02/20/2013 :  17:40:07  Show Profile  Reply with Quote
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
Constraint Violating Yak Guru

USA
279 Posts

Posted - 02/20/2013 :  17:42:56  Show Profile  Reply with Quote
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
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
SQL Server Forums © 2000-2009 SQLTeam Publishing, LLC Go To Top Of Page
This page was generated in 0.06 seconds. Powered By: Snitz Forums 2000