Suppose I was writing an address book application where the details of each contact were stored in an SQL database.A user wants to know all the details for a person whose name is Bob [Someone].In such a case, would writing a query like this be okay?SELECT *FROM contactsWHERE name LIKE 'Bob %';I'm confused because my professor said to avoid using the * wildcard but I can't think of an alternative way of writing it.Is it okay to use the wildcard if I run this query on a seperate thread. Thanks for your help.
Confusion about proper use of * wildcard in SQL
sql
The * is a shorthand for selecting all columns from the result set; the alternative way of writing this is to spell out all the columns you expect in the contacts table, e.g. SELECT id, name, email FROM contacts WHERE name LIKE 'Bob%'.In layman's terms, SELECT name, email FROM ... means tell me the names and e-mail addresses of ..., while SELECT * FROM ... means tell me everything you know about ....The reason people discourage SELECT * are twofold: first of all, if you use it in production code, and the database changes for whichever reasons, your column ordering will be off, and you will be fetching results into the wrong variables. If you specify columns explicitly, you can rely on the correct number and ordering of result columns, and the query will fail loudly if the columns you specify do not match what was found in the database.Another reason is performance. SELECT * means that the DBMS has to perform an extra lookup to get the list of columns. It also means that you haven't thought about what you really need, so chances are you'll be fetching more data than you need, which, considering the typical performance bottlenecks in web applications, is something you really want to avoid.Finally; threads have absolutely nothing to do with this. Nothing at all. I wonder where you got that notion; it looks like you're still quite confused about SQL syntax.TL;DR: SELECT * is OK for queries you fire manually, but you should avoid it in production code, because it can produce unexpected results and may lead to inefficient queries.