[OT] SQL Server DB designed for reporting

2019-01-31 Thread Tom P
Hi Folks I have a normalised database for an application that is working well but is not performant for reporting. I’ve tried and tried to optimise my reporting queries but they are just too slow as the data volume is large in the database. What techniques are there to tackle this? I was thinking

Re: [OT] SQL Server DB designed for reporting

2019-01-31 Thread David Burstin
Might be worth looking into CQRS. Lots of info around about separating databases for reporting and synchronization strategies. Pluralsight has quite a few good courses on CQRS - eg https://www.pluralsight.com/courses/cqrs-in-practice - especially the chapter called "Synchronizing the command and qu

Re: [OT] SQL Server DB designed for reporting

2019-01-31 Thread Tony McGee
One way to do this is to have a regular job that uses SQL Server Integration Services package(s) to extract data from the source system, transform it, cleanse, etc then load it into a destination database (ETL) Often, but not always, the destination database has a star schema with fact and dimensi

Re: [OT] SQL Server DB designed for reporting

2019-01-31 Thread Nathan Schultz
+1 to Tony's answer. Using SSIS (integration services) to export to a reporting database or data warehouse. >From there you can use Power BI (for Dashboards) or something like SSRS (SQL Server Reporting Services) for traditional print invoices and things. It's only if you were building a green-fie

Re: [OT] SQL Server DB designed for reporting

2019-01-31 Thread David Burstin
>> It's only if you were building a green-fields application that you'd look into CQRS - it's not something practical for your existing line of business apps. Hi Nathan, My response is that "it depends". I would certainly not advocate a full separate database approach except in exceptional circum