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 2016 November Database Design: Don’t use, comma separated Tables in SELECT Query, Use Explicit JOINs

Database Design: Don’t use, comma separated Tables in SELECT Query, Use Explicit JOINs

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

In online forums, I am observing one bad query practice. People are using multiple tables in the SELECT query by separating using commas.
Bad Query Like:

1
SELECT * FROM a, b, c WHERE a.id = b.id AND b.id = c.id;

Many of the Database Professionals are thinking that It is working like JOINs.

I am writing this article in the “Database Designing” category, means It applies to all database professionals for knowing the truth of this kind of bad SQL Query.

When you write a query like above sample, internally Query Planner creates a virtual join between these tables and this is not a strait forward joins creation. A Query Planner has to check all possible combinations like: first join A TO B and then join C, join A TO C and then join B, join B TO C and then join A.

When you write such types of bad queries, Query Planner has to do additional work for joining the tables correctly and return the correct result.
But actually It checks the data by creating a full Cartesian Product between these tables which is very costly and slow down the query performance.

We have taken example of three tables only, now let’s assume if we have 10 tables and people wrote a SELECT query using comma separated tables.
So please I am requesting, never use such a bad query and try to write explicit JOINs in the SELECT Query.

Another interesting point is:

When I discussed this point with our team, one of database developers said It is good that Query Planner is deciding the order of JOINS. If we give explicit joins, It may not be in the correct order all the times so let’s Query Planner to do.

My simple answer was:
I am 5% agree with you, but do not forget that we are enough professional and can define the JOINs order correctly. We should not rely on Query Planner because It requires more internal I/O to just prepare a joins of the table.

Correct Query should like:

1
SELECT a.* FROM a JOIN b ON a.id=b.id JOIN c ON b.id=c.id

Nov 30, 2016Anvesh Patel
PostgreSQL: How to calculate RANK in a query (DENSE_RANK())Database Theory: What is difference between MySQL and PostgreSQL?
Anvesh Patel
Anvesh Patel

Database Engineer

November 30, 2016 Database DesigningAnvesh Patel, database, database concept, database research and development, database standards, Database Theory, database topic, dbrnd, explicit joins, implicit joins, joins optimization, performance, RDBMS
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....