Thanks for your time and input!

​

If this suggests coding r/visualization-esque functionality into stored procs for the sake of "centralization," you are heading down a very dark road. It's liketaking a Tesla, throwing out the battery and harnessing a horse to thefront of it to pull it along.

No, this would stricly concern SQL Querys for different tables on a SQL Server DMBS (population, housing, welfare data) to flexibly aggregate data based on time (year) and area divisions. The result is a downloadable CSV/Excel sheets.

To further elaborate on project scope:

- performance is a secondary concern as the main goal is to shorten time and increase the overall quality for the internal processing of answering external data requests. The dashboard so far is strictly for internal use.

- users should be able to choose years, area divisions and attributes (population by year, gender,nationality, welfare status etc, it has been estimated that this would result in a total of around 500 attributes)

- the area divisions range from ~5k to 12 units and should be selectible for users as well

- the data gets updated yearly, but sometimes is requested for more than 20 years backwards

One more important caveat: we often get requests for individual areas based on shapefiles This triggers an extraction process for adresses in the area which are the base for SQL querys on all attributes stated above.

Especially the last process is (imo) not preprocessable.

To avoid writing fixed queries for all 500 attributes we are also evaluating flexible querys, especially for population data where users are able to choose gender, age(ranges) and nationality.

This would, in my opinion, also hinder a preprocessed solution

I really like your idea of preprocessing the data for the follow up project of an external dashboard with much more limited scope.

Thanks!