4

I was looking at this PHP DB library called NotORM and upon reading its docs, I have read about its stand on joins. The argument was basically the performance of a single SQL query with joins vs. using multiple select queries and then cross-referencing the results in the DB abstraction layer.

I have always known that single queries should always be better than using multiple queries so NotORM's idea was new to me. I'm not sure also this because it's only in NotORM that I saw this "feature".

I'd like to ask you guys about your opinion about this.

Which query is better and faster?

This...

SELECT application.*, tag.*
    FROM application
    LEFT JOIN application_tag ON application.id = application_tag.application_id
    LEFT JOIN tag ON application_tag.tag_id = tag.id
    ORDER BY application.id

versus...

SELECT * FROM application LIMIT 4;
SELECT * FROM application_tag WHERE application_id IN ('1', '2', '3', '4');
SELECT * FROM tag WHERE id IN ('21', '22', '23', '24');

Is this second method really practical?

Alberto De Caro
  • 5,147
  • 9
  • 47
  • 73
Noel Llevares
  • 15,018
  • 3
  • 57
  • 81
  • 1
    possible duplicate of [JOIN queries vs multiple queries](http://stackoverflow.com/questions/1067016/join-queries-vs-multiple-queries) – arvidj Aug 14 '15 at 13:48

1 Answers1

1

I would expect the single query to be quite a bit quicker. However will depend on the communication between php and MySQL. When I have tried to benchmark it there has been a noticeable overhead just for doing a query (however simple).

However if the query gets too complicated you land up with something that is hard to maintain.

Another point comes if you are trying to use any custom procedures. For example I needed to do some processing based on Levenshtein distances (ie, how similar words are). The MySQL function I found for this was FAR slower than retrieving the data and processing with PHPs Levenshtein function.

Kickstart
  • 21,403
  • 2
  • 21
  • 33