4 ms·

> I explicitly specify the columns of interest in the select-list (projection), [...] for application reliability reasons. For example, will your application’s

> I explicitly specify the columns of interest in the select-list (projection), [...] for application reliability reasons. For example, will your application’s data processing code suddenly break when a new column has been added or the column order has changed in a table? Application reliability for me is the main reason. Better performance is just a plus.

Mauricebranagh 6y ago
Absolutely this was drummed into me 20+ years ago when I worked on my first major sql based project
- GekkePrutser 6y ago
  But that argument only holds true of you rely on the column order. Most modern applications just specify column names where this doesn't matter. A lot of best practices from 20 years ago are no longer valid. Like the excessive normalisation. These days data storage isn't always the major limiting factor anymore, in many cases it's better to have less tables with more data.
  - deleted 6y ago
    [deleted]
  - Mauricebranagh 6y ago
    Well if your specifying columns your not by definition doing a select *
    - GekkePrutser 6y ago
      I meant specifying columns during extraction of the rows. Like using name=result_row("name") instead of name=result_row(1) The former works even with SELECT * irrespective of the order of the columns. The latter won't.
SpicyLemonZest 6y ago
It's the main reason for me too, but in an increasing number of modern contexts I think making SELECT * work well is part of application reliability. I've encountered quite a few users who add new columns all the time (or consume data from a dozen other groups who add new columns semi-frequently), so if we don't enable them to use SELECT * that just means they have to constantly rebuild and redeploy their data processing code.
- nooorofe 6y ago
  In most cases it is better to let application fail as early as possible when something unexpected occured. By making it more stable that way (SELECT *), you create hidden bugs which hard to detect and recovery is more expensive. It is even more important for data processing pipelines. I add assert/except to my code when it is possible: fail job, analyze, fix/report bug, notify downstream, rerun.

Mauricebranagh 6y ago

Absolutely this was drummed into me 20+ years ago when I worked on my first major sql based project

GekkePrutser 6y ago
But that argument only holds true of you rely on the column order. Most modern applications just specify column names where this doesn't matter. A lot of best practices from 20 years ago are no longer valid. Like the excessive normalisation. These days data storage isn't always the major limiting factor anymore, in many cases it's better to have less tables with more data.
- deleted 6y ago
  [deleted]
- Mauricebranagh 6y ago
  Well if your specifying columns your not by definition doing a select *
  - GekkePrutser 6y ago
    I meant specifying columns during extraction of the rows. Like using name=result_row("name") instead of name=result_row(1) The former works even with SELECT * irrespective of the order of the columns. The latter won't.

SpicyLemonZest 6y ago

It's the main reason for me too, but in an increasing number of modern contexts I think making SELECT * work well is part of application reliability. I've encountered quite a few users who add new columns all the time (or consume data from a dozen other groups who add new columns semi-frequently), so if we don't enable them to use SELECT * that just means they have to constantly rebuild and redeploy their data processing code.

nooorofe 6y ago
In most cases it is better to let application fail as early as possible when something unexpected occured. By making it more stable that way (SELECT *), you create hidden bugs which hard to detect and recovery is more expensive. It is even more important for data processing pipelines. I add assert/except to my code when it is possible: fail job, analyze, fix/report bug, notify downstream, rerun.