First off Zoho Reports (and Zoho in general) is great concept and has quite rich features. I can think of number of improvements that can be added to make it more competitive to some of the other cloud services available which I will propose over time.

My background is in business intelligence, data warehousing, data integration and data quality automation. In such I have worked on a number of tier 1 and tier 2 tools but I see a big gap in SMEs adopting these tools due to cost - and more over SMEs do not have the level of complexity and data volume to need these tools - hence me evaluating Zoho Reports.

I have a few questions related to Query tables and Table architecture, performance and flexibility:

1. Are query tables equivalent to database views on top of database tables (I am assuming MySQL is the cloud database used at Zoho) or do query tables actual store the contents of the SELECT statement applied to the underlying tables?
   
   
   
2. Is the row count of a query table included in calculating the maximum number of rows available in a Zoho subscriptions?
   
   
   
3. Performance wise it would be better to store the results as the business rules and calculations are performed once and therefore latency in running reports and graphs on top of the query table is quicker. I am referring to complex joins with high volume of data. If a query table is really a view, is it possible to store the results of query table in a permanent table structure?
   
   
   
4. Is it possible to add indexes to underlying tables? Is this through a GUI interface or can I create Index statements (I am well versed with SQL)?
   
   
   
5. Can I run an UPDATE/INSERT/DELETE statement directly on the underlying table without having to use a query table structure with a SELECT statement? This is without using an API as the scripts will end up sitting outside the Zoho environment. Think MS Access query objects with Create Table, Update, Insert, Delete capabilities.
   
   This is equivalent to applying business rules and data quality rules at the source database table rather than proliferating a number of query table structures. Once again my perspective is on improving performance and reducing proliferation of query tables by applying rules directly on the source table.
   
   Here is an example: Say we have a Customer base table we just uploaded and we want to add Customer Segmentation, Age Range Buckets based on date of birth, fix phone number formats based on a few data quality rules and so on.
   
   
   
   

Sunil