What is the reason not to use select *?

Question

I\'ve seen a number of people claim that you should specifically name each column you want in your select query.

Assuming I\'m going to use all of the columns anyway

Answer 1

One major reason is that if you ever add/remove columns from your table, any query/procedure that is making a SELECT * call will now be getting more or less columns of data than expected.

Answer 2

It makes your code more ambiguous and more difficult to maintain; because you're adding extra unused data to the domain, and it's not clear which you've intended and which not. (It also suggests that you might not know, or care.)

Answer 3

Even if you use every column but address the row array by numeric index you will have problems if you add another row later on.

So basically it is a question of maintainability! If you don't use the * selector you will not have to worry about your queries.

Answer 4

There are a few reasons:

1. If the number of columns in a database changes and your application expects there to be a certain number...
2. If the order of columns in a database changes and your application expects them to be in a certain order...
3. Memory overhead. 8 unnecessary INTEGER columns would add 32 bytes of wasted memory. That doesn't sound like a lot, but this is for each query and INTEGER is one of the small column types... the extra columns are more likely to be VARCHAR or TEXT columns, which adds up quicker.
4. Network overhead. Related to memory overhead: if I issue 30,000 queries and have 8 unnecessary INTEGER columns, I've wasted 960kB of bandwidth. VARCHAR and TEXT columns are likely to be considerably larger.

Note: I chose INTEGER in the above example because they have a fixed size of 4 bytes.

Answer 5

SELECT * is not always evil. In my opinion, at least. I use it quite often for dynamic queries returning a whole table, plus some computed fields.

For instance, I want to compute geographical geometries from a "normal" table, that is a table without any geometry field, but with fields containing coordinates. I use postgresql, and its spatial extension postgis. But the principle applies for many other cases.

An example:

• a table of places, with coordinates stored in fields labeled x, y, z:

  CREATE TABLE places (place_id integer, x numeric(10, 3), y numeric(10, 3), z numeric(10, 3), description varchar);

• let's feed it with a few example values:

  INSERT INTO places (place_id, x, y, z, description) VALUES
  (1, 2.295, 48.863, 64, 'Paris, Place de l\'Étoile'),
  (2, 2.945, 48.858, 40, 'Paris, Tour Eiffel'),
  (3, 0.373, 43.958, 90, 'Condom, Cathédrale St-Pierre');

• I want to be able to map the contents of this table, using some GIS client. The normal way is to add a geometry field to the table, and build the geometry, based on the coordinates. But I would prefer to get a dynamic query: this way, when I change coordinates (corrections, more accuracy, etc.), the objects mapped actually move, dynamically. So here is the query with the SELECT *:

  CREATE OR REPLACE VIEW places_points AS
  SELECT *,
  GeomFromewkt('SRID=4326; POINT ('|| x || ' ' || y || ' ' || z || ')')
  FROM places;

  Refer to postgis, for GeomFromewkt() function use.

• Here is the result:

  SELECT * FROM places_points;

 place_id |   x   |   y    |   z    |         description          |                            geomfromewkt                            
----------+-------+--------+--------+------------------------------+--------------------------------------------------------------------  
        1 | 2.295 | 48.863 | 64.000 | Paris, Place de l'Étoile     | 01010000A0E61000005C8FC2F5285C02405839B4C8766E48400000000000005040  
        2 | 2.945 | 48.858 | 40.000 | Paris, Tour Eiffel           | 01010000A0E61000008FC2F5285C8F0740E7FBA9F1D26D48400000000000004440
        3 | 0.373 | 43.958 | 90.000 | Condom, Cathédrale St-Pierre | 01010000A0E6100000AC1C5A643BDFD73FB4C876BE9FFA45400000000000805640
(3 lignes)

The rightmost column can now be used by any GIS program to properly map the points.

• If, in the future, some fields get added to the table: no worries, I just have to run again the same VIEW definition.

I wish the definition of the VIEW could be kept "as is", with the *, but hélas it is not the case: this is how it is internally stored by postgresql:

SELECT places.place_id, places.x, places.y, places.z, places.description, geomfromewkt(((((('SRID=4326; POINT ('::text || places.x) || ' '::text) || places.y) || ' '::text) || places.z) || ')'::text) AS geomfromewkt FROM places;

Answer 6

because "select * " will waste memory when you don't need all the fields.But for sql server, their performence are the same.