best practices

Avoiding select * has more to do with performance and self-documenting of code than with reducing risk. Andrew touched on the performance aspect. Two common issues that are encountered down the road on a successful project are adding new columns to the database that are irrelevant on the Web page using select *, and adding a new person to the project, such as a consultant, that is trying to figure out how the page works and encounters a mystery * that requires a visit to the database to figure out instead of a convenient list of columns right there in the page where the columns are used. -Mike Chabot On Mon, Aug 13, 2012 at 8:42 PM, Andrew Scott <andrews@andyscott.id.au>wrote: > > There is a performance issue to consider, for example you may have a 100 > columns but only actually use say 15 of them. Thus you are sending more > data over the wire than you actually need, on top of that there is caching > and indexing to consider which will also degrade performance. > > For the database to know what columns are there, and since you're not > giving your database any hints as to what you want, it will first need to > check the table's definition in order to determine the columns on that > table. That lookup will cost some time - not much in a single query - but > it adds up over time > > This is only a small snippet of the problem, and you would need to > understand how databases works to fully understand the problem. > > > -- > Regards, > Andrew Scott > WebSite: http://www.andyscott.id.au/ > Google+: http://plus.google.com/113032480415921517411<; > http://plus.google.com/108193156965451149543>; > > > > > > > > > Hi Folks > > > > several commented that select * is not good practice. > > The tables I have are relatively small approx 40 columns and I use all of > > the > > them. > > is there a risk in using the select * > > > > Thanks > > Rob > >