Database Research & Development

  • Home
  • NoSQL
    • NoSQL
    • Cassandra
  • Databases
    • Database Theory
    • Database Designing
    • SQL Server Coding Standards
    • SQL Server
    • PostgreSQL
    • MySQL
    • Greenplum
    • Linux
  • Interviews
    • SQL Server Interviews
    • MySQL Interviews
    • SQL Puzzles
  • DBA Scripts
    • SQL Server DBA Scripts
    • PostgreSQL DBA Scripts
    • MySQL DBA Scripts
    • Greenplum DBA Scripts
  • Home
  • Blog Archives !
  • (: Laugh@dbrnd :)
  • Contact Me !
sqlserverinterviews
Home 2015 September SELECT all columns to be good or bad in database system

SELECT all columns to be good or bad in database system

This article is half-done without your Comment! *** Please share your thoughts via Comment ***

In this post, I am going to write about one of the most common mistakes of Database Developers.

“SELECT * ” (SELECT all columns) to be good or bad in a Database System.

I will discuss the pros and cons of “SELECT * ” and what should be our best practice with SELECT all columns.

Don’t go with ” SELECT * “:

  • When you are using ” SELECT * “, you are selecting more columns from the database, and your application might not use some of this column. This will create extra cost and load on the database system, and unnecessary data travels across the network.

  • When you are using JOIN between two or more tables, and in that query, you use “SELECT * “, guess about two columns with the same name. It will return more columns than you needed and will create a binding problem.

  • If you are using “SELECT * “, you may get all columns in arbitrary sequence, and if specified the column name, it will return in the specified order, and you can also refer to this column by numerical index.
    If such a code exists in an application which requires all columns in a predefined order, you have to specify all the columns name in the correct order.


  • When you are using “SELECT *”, you will face performance issue because this is not advisable to apply an index on all the columns of the table.

  • When you are using “SELECT *”, you require to create documentation for those columns which are returning and using by an application otherwise, this will create confusion.

  • When you are using “SELECT * ” and in the future, someone adds one new column with TEXT data type, you can imagine performance and other errors.

  • If you need to select all columns, also I would suggest providing a full list of columns because putting “SELECT *” needs fetching the name of the columns from stored metadata or system information which will impact the query performance.

  • Now Imagine that you are using “SELECT *” in all your stored procedure and now you require to find one column name from the text of the stored procedure which is not possible with “SELECT *”.

Why you go with “SELECT *” ?

  • The Lazy developers can only go with “SELECT *”.

  • If you have special requirements and create a dynamic environment when add or delete column automatically handle by application code. In this particular case, you don’t require to change application and database code, and this will automatically be done in a production environment. In this case, you can use “SELECT *”.

  • I didn’t find any other reason to use “SELECT *”.
Sep 3, 2015Anvesh Patel
How to Insert if not exists in MySQLDifference between datetime and timestamp in MySQL
Comments: 2
  1. Surendranatha Reddy Chappidi
    February 7, 2019 at 10:37 am

    Good points about how select * impacts the performance of query .

  2. Sarfraj Shaikh
    April 8, 2019 at 2:17 pm

    Good one !

Anvesh Patel
Anvesh Patel

Database Engineer

September 3, 2015 Database DesigningAnvesh Patel, database, database concept, database research and development, database standards, Database Theory, database topic, dbrnd, RDBMS, select
About Me!

I'm Anvesh Patel, a Database Engineer certified by Oracle and IBM. I'm working as a Database Architect, Database Optimizer, Database Administrator, Database Developer. Providing the best articles and solutions for different problems in the best manner through my blogs is my passion. I have more than six years of experience with various RDBMS products like MSSQL Server, PostgreSQL, MySQL, Greenplum and currently learning and doing research on BIGData and NoSQL technology. -- Hyderabad, India.

About DBRND !

dbrnd

This is a personal blog (www.dbrnd.com).

Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated.

Feel free to challenge me, disagree with me, or tell me I’m completely nuts in the comments section of each blog entry, but I reserve the right to delete any comment for any reason whatsoever (abusive, profane, rude, or anonymous comments) - so keep it polite.

The content of this website is protected by copyright. No portion of this website may be copied or replicated in any form without the written consent of the website owner.

Recent Comments !
  • Anvesh Patel { Sure will do... } – May 27, 12:43 PM
  • Anvesh Patel { Great... } – May 27, 12:41 PM
  • Anvesh Patel { Great... } – May 27, 12:39 PM
  • Anvesh Patel { Great... } – May 27, 12:36 PM
  • Anvesh Patel { Great... } – May 27, 12:28 PM
  • Anvesh Patel { Great... } – May 27, 12:27 PM
  • Anvesh Patel { Great... } – May 27, 12:16 PM
  • Older »
Follow Me !
  • facebook
  • linkedin
  • twitter
  • youtube
  • google
  • flickr
© 2015 – 2019 All rights reserved. Database Research & Development (dbrnd.com)
Posting....