DNG : recommendation on adding columns in a view in DNG. CLM 6.0.6.1
Accepted answer
There are some considerations:
1. USABILITY: IMO it's better to have a small number of focused, regularly used views than a large number of views to cover occasional needs (which as a user can make it hard to find the one you want) or to have views with very many columns (most of which are ignored most of the time). So it's good you are thinking through this intentionally so you can find a "sweet spot". It's also helpful to provide shared views for all users which they can customize and save as a personal view (for example, to add a column or different sorting to accomplish a one-time task or a task only they perform). Naming your views in an intentional hierarchy makes them much easier for users to find (and to predict which view will meed their immediate need).
2. SYSTEM PERFORMANCE: Every additional column makes the queries to the database more complex and sends more data over the wire from server to browser. Better to be parsimonious rather than profligate. The one exception is if you are exporting to CSV or Excel to do further analysis or reporting outside DNG and Report Builder. In this case it's common to include columns for all attributes you may find you need (note that doing this via Report Builder won't put load on the DNG server).
Comments
The answer is very useful and quite informative.
So does that means theoretically DNG does not impose any limit on adding columns to a view but practical limits are there???
In our environment we have "Requirement Authoring View" which has all attributes added as columns. I may have to break down this view into multiple views for better performance.
Still is there any specific number of columns that DNG recommends to have in the view or is it upto the user to investigate and find out??
As the type system is fully customizable, how could DNG recommend anything?
This should always be driven by common sense. I do not know anything about the implementation, but common sense says that there could or could not be limits in the number of columns one could configure.
There is a practical limit that is likely reached first - the width of your screen and how much you accept scrolling.
The next practical limit is likely load times.
I think a useful heuristic is "no more columns than can fit on an external monitor without scrolling". This is more about (1) in my original post than (2). It would be interesting to hear from others on this point.
Regarding (2) there are two special columns that involve many more queries and thus IMO should only be included on a minority of views where they are really needed: the comments column and the link validity column.
I was looking for something specific like this link with respect to DNG but unfortunately I could not find anything.
It looks like its upto the user to find out the "sweet spot" that works for him as pointed by Daniel.