Hacker News Reader

Comment by eschutte2 | Hacker News Reader

Yeah, you definitely don't want to be making those roundtrips. Why doesn't a join work?

Complex domain-specific requirements preclude simple joins unfortunately. This is why I'd like to redevelop these queries in C#. There are many imperative steps performed on each time series record to decide how these reports are generated.

To give a very broad example of one report: take 10,000 latest time series records from geographic location X. Now for each of those records load the latest 100 time series records from location Y and Z. Multiply all records from Y and Z together then divide by the value at location X. Throw in lots of business rules at every one of these steps so we have no chance of representing this as a tidy join operation and so that we can make no assumptions about the data we'll need to load to generate the report :)

Have you tried loading all the data required and then munging it in c#?

Edit - returning multiple result sets from the server is always an option too.

> Have you tried loading all the data required...

Sorry, I probably edited my post while you were typing. The amount of data to load is theoretically unbounded (could load the entire data set for a big report) and it's very difficult to estimate ahead of time which data needs to be loaded. This is because the data in the time series dictates which secondary sets of data will be loaded on a record-by-record basis.

If it's not possible to do a few big queries to pull all the necessary base data (all the related Ys and Zs for the last 10,000 Xs) and then join/filter it yourself in code, then I think you are stuck with many queries. The options I can think of are: 1) keep the logic in stored procedures; 2) find a way to fetch the raw data in a few large queries, then join yourself; 3) let the reports be slow and generate them in the background; 4) write one complex SQL query that does all the crunching (if possible, you're saying it's not).

> If it's not possible to do a few big queries...

Yeah, this is the unfortunate conclusion that I arrived at too. I'm looking at making these reports go through a job queue which e-mails the result to the user when it's done. This would allow me to develop much more complex, but much slower queries in C#.

Reply on news.ycombinator.com