To apply NarrowViews means accessing only those fields in a database that are really needed for a use case.
For an order processing system you want to design a dialog box to select orders by customer and to view them. You have already defined a Physical View for orders and as you have use cases that process more than one order at a time, you have implemented a readMultiple() method that delivers a set of orders for a given customer.
What kind of views should you use for filling list boxes?
Flexibility vs. Protection: The natural way to fill a list box is a dynamic SQL query. Such queries are most flexible and are the best fit for query by example. Anyway some database administrators will not allow you to use dynamic SQL for reasons of access protection or database load as user defined queries cannot be controlled by a central database administration. They can cross police lines in an unprotected database and might also cause uncontrollable database load in large online systems, impairing other users. So the views you need will typically be shielded by Physical Views. Each physical view is a code object. An explosion of code objects is always considered negative.
Performance: On the other hand you always want to economize on bandwidth. You want to transport only those data from the database that are really needed. This is especially important if you have a Client/Server cut between the object that consumes the data (the list box) and the object that provides the data (the database).
Use narrow views. Views for list boxes should contain the data needed in the list box and the primary key to access the object that you intend to select from the list box.
Cost and Performance: You will have a second set of Physical Views for filling list boxes. This increases the amount of code objects in a system. On the other hand you have maximum efficiency.
For reasons of clarity we have factored out the second rule for list boxes in the ShortViews pattern.