"rather than using SELECT . If you do use SELECT , don't assume that the fields are in a particular order."
There are professional developers that use Select * EVER!
Maybe add write a simple Select, Insert and Update Statement to the FizBuzz test.
There are professional developers that use Select * EVER!
Maybe add write a simple Select, Insert and Update Statement to the FizBuzz test.
However, "SELECT * FROM SomeTable" can be used to determine if a table had data ( for "EXISTS" clause ) or to "COUNT" the rows of the table. It's industry standard.
You could also use something like "SELECT 1 FROM SomeTable" but it isn't natural.
If you always use column names, why does column order matter?
Another time when you don’t want to do select * is if you are using a database that does columnar storage like Redshift.
If you want to change it to SELECT 'EXISTS' then I wont be mad :)
There is nothing wrong with a select * when working with an unfamiliar data model for initial rough development to get your head around the data path. Just remember to refine your query to meet your performance requirements.
One would catch a lot of debate (never use an ORM), the other mostly doesn't (never use select *). Maybe most people that use an ORM don't connect these dots though.
function lookupFoo(baz) {
const sql = await db.init();
const result = await sql.query`
SELECT x, y, z
FROM foo
WHERE bar = ${baz}
`;
return result.records.map(mapResultsToFoo)[0];
}Hibernate doesn't for starters.
Old code from the 2000 PHP era is full of this. Never underestimate the horrors of "legacy" code bases, and never underestimate what people do in short lived "maintenance scripts" or "helpers" that are used well beyond the intended life span. Or "proofs of concept" aka "unbelievably dirty hacks to get a MVP" that end up being extended and extended to being the "real product" in the end.
For an MVP I will always use "select *" and friends simply for speed of development, but clearly communicate that this is in no way intended for production usage.
But it likely will be anyway.
I use a variety of ORMs and hand-rolled SQL, and often will do select . The times when I know there may be a performance impact, or I'm debugging an existing performance impact, hand-rolled SQL always is on the table, but often* the issue is either missing/poor indexes or simply table design that didn't foresee the current use case. There's been a couple of times where a stray select * was, really, pulling back unintended very large blobs and causing a performance issue, but it's been infrequent compared to index issues.