Karen:
My vote is for explicitly defined column sets within views: 1. Local hardware resources. On a stand-alone modern workstation, data 'bloat' is no big deal relative to disc access/ ram/ cpu speed below a certain view scale. Hard to guess/pinpoint in advance. 2. Network resources. On a LAN/ TS network, 'bloat' could be a really big deal at the server end. Multiply LAN impacts by the number of simultaneous users. Troubleshooting requires tightening up the view anyway, so why not? 3. Distributed device resources. What gets by on a muscular workstation might choke a small tablet in a multi-device distribution. 4. Coding. Explicitly defined columns make the intent of code easier to discern and troubleshoot. 5. Viewing. 'Narrower' views make it easier to visually scan and analyze browsed views during testing and troubleshooting. Bruce Chitiea SafeSectors, Inc. 909.238.9012 mobile ----------------------------------------------- On 2015-11-24 10:33, Karen Tellef wrote: > Since the list's been slow, let me bounce this off everyone. > > Back in the "old" days I usually avoided views using the wildcard, like: > select t1.*, t2.* from table1 t1, table2 t2.... > because the view would break if you added or removed columns to the > referenced tables. Now we don't have that problem anymore. > > Just now I removed a column from a table and I had to modify the defintion of > 6 views because they specifically mentioned that column. So, is there any > efficiency gained by referencing specific column names in views rather than > using the "t1.*" syntax? I've always wondered if you were, for example, > querying a view that might list 10 specific columns between 2 tables, rather > than using the wildcard which might result in a view with 50 columns. If > there's no efficiency in a fewer number of columns, then I think I'm going to > always use the "t1.*" so I don't have to worry about new/deleted columns. > > I'm not sure if this is a question that only RBTI would know the answer to. > > Thanks! > > Karen
