05-22-2011 01:58 AM
07-04-2011 03:58 AM
There's not really a document explaining how to think about imap and reports. It's more a logic thinking.
Check the number of reports who are going to get data from the same tables. Make grouping. These reports then are using the same information map.
But, yes there's always a but, think about the number of joins between tables. If you have a report who's using two tables (A and B) and your other report is using also A but C check the performance because the imap will join the 3 tables before the reporting.
the amount of records is also important, if your tables are small then you can have a huge imap.
08-31-2011 09:54 AM
The limit is a practical one. If you create an information map with hundreds or thousands of data items, then the performance is going to be poor. In addition, information maps are intended to provide an easy interface to a specific subset of data to non-technical end users. So, typically, you would not simply create information maps that include all columns from a data source. For instance, a report creator will likely have a difficult time trying to navigate through 2000 data items to find just those data items that are useful for one report, even if the data items are in separate folders. Instead, you should create multiple information maps, each containing a selected number of columns that serve a particular reporting need.