The first you have correctly identified, unless you are careful with your universe resource limit settings then your end users “could” adversly affect the performance of your live system. Remember it’s not just the database resources – think network bandwidth and also queries paging “current” data out of memory by reporting on “historic” data.

The second is concerning reproducable results. If you are accessing a “live” system then everyone must understand that the results on their report are “live” and they should not expect two copies, even if they were refreshed only seconds apart, to reconcile.

Ross

Do you see any issues with building a new universe using a connection to a live data source? Apart from the possibility of test queries using up database server resources I don’t see any particular problem. The universe would be hidden from all users except me.

Cheers
CC

So, Let me get it clear, you are recommending that if pre-defined condition is used by one report then it should be built on the report manually using universe object and if pre-defined condition is used by multiple reports then it should be defined in universe as universe filter.

Would you consider defining all pre-defined condition objects in universe rather than building it up in the report? If yes, then what are the benefits?

If it “must always” be there, define it in the universe as a self restricting join on the table it’s self.

If it “should mostly” be there, define it in the universe as a self restricting join on the table it’s self but with a prompt to allow it to be disabled.

If it should be used “sometimes” then it should be a pre-defined universe filter object and the user should select, on a report by report basis, if it should be used.

If it only makes sense on one report then the condition should be built on the report using the existing objects and manually defining the condition.

Good info…
What would you recommend and why for conditions, which are static filter should be created within universe or within report?