But the question is also interesting, such as the wildcard(*) issue in select.
You want to make a flexible/scalable system. That works even with new columns. Then you make a system that searches for which columns exist (metadata) and deletes the ones you’re sure you won’t need. Very well, you are creating a system concerned with data traffic (considering that it is cached metadata, of course) but not traffic (amount of queries).
Only that you pass this overhead to the application server, because as our friend Renan said, they did not create it in SQL (it would generate a lot of overhead for the BD, because although the logic is simple, it would need to be done in all types of query). Won data, lost performance. Of course, the lost performance depends on the availability of your application. Systems that have no problems with multiple/concurrent access have no problem with this.
Now, another note. What if the column that was added semantically has to go to the list of exceptions? Um, and even worse, if its meaning asks other listed columns (brought yes by select) to enter the exceptions? Worse: and if ....
All right, this problem has a solution, called parameterization. the user or a configuration file - or yet another system - define both incoming and non-incoming query fields.
Problems? Yes, parameterization is one of the most debated paradigms of programming: how to parameterize, what to parameterize, when, and so on. Yes, because that’s why generates code harder to create and maintain despite diminishing it.
Parameterization increases overhead as well (mainly from the programmer).
But all this could be solved with wildcard (*); because the system you are doing is simple. Or just a few columns.
It is known more or less :) There are controversies (http://answall.com/a/22835/101). There has not yet been a single answer there that shows all the important points, that shows that there are cases and cases, but reading all the answers gives a broader idea about the subject. Anyway the question itself is good.
– Maniero
@bigown Basically, if you need all the data, use
*
, If not, look only for what you need, more fields result in loss of performance.– Kazzkiq
I would say different, if you need some fields and need performance and measured that using * would be problematic, and that your application does not need to receive the columns that exist in the table (the application will know how to handle columns that the application did not even foresee) as opposed to receiving specific columns (I realize that most programmers don’t know how to make flexible software), and I’m citing just a few restrictions for choosing to list the fields, the * is the best option. Choosing almost all or all is the same thing in almost every case. Of course it has to see the specific case.
– Maniero
Some answers depend on how the data is used, a simple report may receive a metadata processing so that a possible new column is added automatically but for a calculation will always need to change the logic.
– Motta
@Kazzkiq with correct cache handling, the loss of performance due to having all fields in the query is not significant ;)
– Oralista de Sistemas
Just to complement, there is no problem in the query being "gigantic" by this aspect. What can be a sign of problems is query complex too, which is independent of the size "texual".
– Bacco