5 ms·

I feel like this is a weird title. An equivalently bad title would be "SELECTing fewer columns than you need is bad for correctness." "SELECT *" should be just

I feel like this is a weird title. An equivalently bad title would be "SELECTing fewer columns than you need is bad for correctness." "SELECT *" should be just as performant as "SELECT A, B, C" when your object only has A, B and C as columns.

wyattpeak 6y ago
It's fine for now, but it makes assumptions about the future state of your database. The arguments presented in the article may or may not be applicable to your particular application, but I think it's a solid principle that you shouldn't assume your database will retain its schema indefinitely. If you're relying on "SELECT *" to mean "SELECT A, B, C", you're in for a bad time.
- lemagedurage 6y ago
  Maybe you're relying on your ORM object to have all columns available, even when you add more, and you're in for a good time.
- ellisv 6y ago
  > but I think it's a solid principle that you shouldn't assume your database will retain its schema indefinitely. this is not a hard thing to anticipate and yet my coworkers thought otherwise...
kaushikt 6y ago
Perhaps to begin with just having A,B,C columns are fine and your comment justifies. However, it still stands true in a test of time when you will end up with a lot more columns.
- Semaphor 6y ago
  And when you add columns you need to a table, you will also need to add them to your query. But I didn’t say it’s a good idea to do SELECT * (I never use it outside manual queries), just that it has no performance implication just by virtue of using it.
tinus_hn 6y ago
And will never have more columns
coldtea 6y ago
That's a non-useful pedantic correction, if I ever saw one...
jameshart 6y ago
SELECT * is quicker to transmit as a query, contains less tokens to parse, requires no lookups to column metadata to map from stored data structure to result structure... I’m pretty sure there must be some circumstances where it outperforms an explicit SELECT a, b, c query.

wyattpeak 6y ago

It's fine for now, but it makes assumptions about the future state of your database. The arguments presented in the article may or may not be applicable to your particular application, but I think it's a solid principle that you shouldn't assume your database will retain its schema indefinitely. If you're relying on "SELECT *" to mean "SELECT A, B, C", you're in for a bad time.

lemagedurage 6y ago
Maybe you're relying on your ORM object to have all columns available, even when you add more, and you're in for a good time.
ellisv 6y ago
> but I think it's a solid principle that you shouldn't assume your database will retain its schema indefinitely. this is not a hard thing to anticipate and yet my coworkers thought otherwise...

kaushikt 6y ago

Perhaps to begin with just having A,B,C columns are fine and your comment justifies. However, it still stands true in a test of time when you will end up with a lot more columns.

Semaphor 6y ago
And when you add columns you need to a table, you will also need to add them to your query. But I didn’t say it’s a good idea to do SELECT * (I never use it outside manual queries), just that it has no performance implication just by virtue of using it.

tinus_hn 6y ago

And will never have more columns

coldtea 6y ago

That's a non-useful pedantic correction, if I ever saw one...

jameshart 6y ago

SELECT * is quicker to transmit as a query, contains less tokens to parse, requires no lookups to column metadata to map from stored data structure to result structure... I’m pretty sure there must be some circumstances where it outperforms an explicit SELECT a, b, c query.