I have two database tables, subscription and transaction, where one subscription can have many transactions. The status of the subscription depends mainly on the transactions that belong to it. So if I want to calculate next process date I would look at the period field of the subscription object and then analyze the subscription’s transactions to determine its status. This all works fine.
The problem that I am facing is that the table contains over 400,000 subscription objects and millions of transaction records, so it’s getting kinda tricky to build a report summary of the subscriptions (like how many of each from about ten possible statuses that are calculated dynamically)
Since all of the logic to calculate the status of each subscription is in the c# code, I have to load an entire graph of subscription objects with all of their child transaction objects using linq-to-sql. This is taking quite a long time, maybe two minutes or so. I’m looking at caching, but won’t give real-time results. I’m just wondering if there is a strategy in place that could solve this, or maybe a index on my database that may speed the linq to sql query up. Or if I just designed it horribly from the beginning.
Thanks.
Perhaps you shouldn’t load all this data in the client and do all the calculations row by row. This is what databases are actually good at. Do the calculation on server side, better still have the calculation stored in the tables and just look it up in your reports. If you have 400k subscriptions and +M transactions then the corner stone of your design is the database, not the client. You need to invest your time and design in the data model, and the client comes after that.