Is it too much to ask MS for a simple ad-hoc query tool for end users?

Question

Hello
This is a general MS BI topic and not specific to Power Query, but I couldn't find a more suitable general forum for it.
This posting is the result of the frustration I have with MS BI stack, whereby a simple ad-hoc drag and drop query tool to get the data in a table format (preferably from a relational
data source) is missing, something that other big vendors have, such as SAP Business Objects Universe and the associated tools. The deprecated SSRS Report model and SMDL was the closest MS ever got to this functionality (although that had some limitations
too), which unfortunately is dead now in favour of all sort of "Power" tools that basically can’t deliver the same functionality.
The requirement is pretty simple: provide users with a tool that they can drag and drop fields from different entities in a data model without having to worry about entity relationships and
apply necessary filters and get the data out in Excel or CSV, no fancy (or even simple) aggregation or formatting is required, and users should only see the rows they are authorized to see, i.e. row level security (RLS) of data.
Let’s see what we have at our disposal from MS BI:
From the modeling perspective, we have relational models in the database that support RLS with views, but obviously cannot maintain PK-FK relationships in the database model between views. Other
models are .Net Entity Data model Framework model exposed as OData, and SSAS tabular, SSAS PowerPivot, SSAS multidimensional, which you can find a good comparison of their features here:
http://www.sqlchick.com/entries/2012/3/4/decisions-powerpivot-ssas-tabular -or-ssas-multidimensional-m.html
From the tools perspective we have:
Power Query on top of a relational database (SQL Server): Can connect to relational databases easily, generated queries are optimal, detects relationships with entities, but only when entities
are tables and have PK-FK relationships enforced in the database. So can’t detect relationships with views and hence can’t enforce RLS, so this is not an option unless users keep joining entities, which is not a desirable option either.
Power Query on top of an OData: Works well except that queries generated for multiple entity expansion are terrible (look here for more details:
http://social.technet.microsoft.com/Forums/en-US/7a8b8e52-d3a9-42af-bc52-9d5459c00529/odata-multilevel-expand-query-issue?forum=powerquery). In addition all filtering and projections are done at client side, so even if you want 1 row out of 1 million, all
rows are brought over to Excel before filtered. Overall this results in unacceptable performance even for small sized data.
Power Query on top of a tabular model: Doesn’t support that type of data source yet (http://social.technet.microsoft.com/Forums/en-US/ebcccb5e-7058-4046-917d-3d7fcf60cbdc/tabular-model-as-data-source-for-power-query?forum=powerquery).
Even if it did, tabular models don’t support Many-to-Many relationships out of the box and not sure if there are plans to support tabular models in Direct Query mode in Power Query to take care of RLS.
Excel on top of tabular models or multidimensional models: The tabular model should not be in Direct Query mode and you only get to use PivotTable to query the model. PivotTables are not famous
for generating optimal MDX queries, so performance is not going to be acceptable if you are dealing with large dimensions, especially large junk and degenerate dimensions. You can use drilltrough to get details of a measure, but you have to specify the columns
for a drilltrough action upfront, no flexibility for users to select what they want to see.
PowerPivot on top of relational databases: The query designer cannot detect relationships between views, so users have to perform manual joins, not an option.
PowerPivot on top of a multidimensional or tabular model: The query designer doesn’t generate optimal MDX queries by drag and drop. Especially there doesn’t seem to be a way to add related
attributes of a dimension attribute to the query without cross joins which results in poor performance on large dimensions. Other issues found here
http://sqlblog.com/blogs/marco_russo/archive/2010/08/24/using-ssas-2005-2008-as-powerpivot-data-source-query-designer.aspx. In addition the result set has ugly column names and issues with data types, such as interpreting numeric data types as Text, and
there’s no straight forward way of getting the data from PowerPivot directly to Excel. The user either has to do a copy/paste (which doesn’t work on large datasets) or create a pivot table, bring the measure, and drillthrough the measure to get the details
in table format.
PowerPivot with OData: Treats every entity as a separate table to import, not suitable for our use case.
Report Builder and SSRS on top of relational, multidimensional or tabular model: Given the query designer is the same as PowerPivot, it has similar issues. In addition, there are 4 more steps
from designing a query to generating an Excel or CSV output, not an option.
PowerView: Works against tabular and multidimensional models, but there’s no way of exporting data to Excel sheet. Besides the add-in is not available for Excel 2010.
Good old MS-Access: Link to tables and views through ODBC, create relationships between entities and give each user a copy of that Access database to create their queries, and deal with the
nightmares of updates to the model and distribution of new models to the users! Did I mention Access as an option?
So there you go, 10 options, none of which can deal with a seemingly simple use case sufficiently. At the moment, the best among them appears to be option 6 against a heavily optimized OLAP
cube, and perhaps #3 when/if Power Query support for tabular models in direct query mode arrives. Perhaps I am missing something very obvious, and would like someone to enlighten me here.
Thanks
MR

Answer 1

Hi, as far as I can infer, that term means it's not loading any resources until needed, opposite of this...
-bind_at_load
                 Sets a bit in the mach header of the resulting binary which tells dyld to bind all symbols                when the binary is loaded, rather than lazily.
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/ man1/ld.1.html
Load resources lazily.
You should never load a resource file until it is actually needed. Prefetching resource files may seem like a way to save time, but this practice actually slows down your app right away. In addition, if you end up not using the resource, loading it wastes memory for no good purpose.
http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneos programmingguide/PerformanceTuning/PerformanceTuning.html
And, higher OS versionsare even worse with Bonjour/mDNSResponder, but might see this...
http://support.apple.com/kb/ht3789