I came across an article about Join decomposition.
SCENARIO #1 (Not good):
Select * from tag
Join tag_post ON tag_post.tag_id=tag.id
Join post ON tag_post.post_id=post.id
Where tag.tag='mysql'
SCENARIO #2 (good):
Select * from tag where tag='mysql'
Select * from tag_post Where tag_id=1234
Select * from post where post.id in (123,456,9098,545)
It was suggested to stick to scenario #2 for many reasons specially caching.
The question is how to join inside our application. Could u give us an example with PHP
after retrieving them individually?
(I have read MyISAM Performance: Join Decomposition?
but it did not help)
You COULD use an SQL subselect (if I understand your question). Using PHP would be rather odd while SQL has all the capabilities.
I’m not sure how your database structure looks like, but this should get you started. It’s pretty much SQL inception. A query within a query. You can select data using the result of a subselect.
Please, before copying this SQL and telling me it’s not working, verify all table and column names.
Before anyone starts to cry about speed, caching and efficiency: I think this is rather efficient. Instead of selecting ALL data and loop through it using PHP you can just select smaller bits using native SQL as it was ment to be used.
Again, I highly discourage to use PHP to get specific data. SQL is all you need.
edit: here’s your script
Assuming you have some multi-dimensional arrays containing all data:
If you look at the length of the script above, this is exactly why I’d stick to SQL.
Now, as I recall, you wanted to
joinusing PHP, rather doing it in SQL. This is not a join but getting results using some arrays. I know, but a join would only be a waste of time and less efficient than just leaving all results as they are.edit: 21-12-12 as result of comments below
I’ve done a little benchmark and the results are quite stunning:
Even though the subselect returns much less data, the duration of the requests is nearly 10 times longer…
I’ve NEVER expected these results, so I’m convinced and I will certainly use this information when I know that performance is important however I will still use SQL for smaller operations hehe…