Il existe une autre solution que 1000 requêtes, c'est de récupérer le contenu de la table "employee", de la stocker dans un tableau, de récupérer le contenu de la table "operation_commercial" et de les trier dans le tableau d'employe => 2 requetes.

Pour les immenses table (plusieurs millions d'enregistrements) cette solution est la mieux (+ rapide, - bloquante pour le SGBD)

Mais, généralement, il vaut mieux laisser au SGBD faire le travail de jointure, il est optimisé pour

Je suis pas sur que PHP apprécie beaucoup ça en mémoire ... pourquoi boucler en PHP quand ton sgbd boucle beaucoup plus rapidement directement en C ?

Parce que, même avec Oracle, faire une jointure entre 2 tables de 10 000 000 de lignes, c'est encore PHP qui occupe le moins de mémoire et de CPU

dans cette configuration, oui j'utilise les index.
Mieux vaut une requete en plus que d'utilisez une jointure, qui bouffe la mémoire jusqu'à la corde. Sa coute plus chère en requete mais ton appli va plus vite et sa n'a pas de prix.
Alors après tu peux argumenter que tu va mettre un système de cache...
Moi je dit, simplicité.

Je suis contre cette forme de développement où on est sûr de ses croyances.

Les jointures peuvent être et sont très souvent plus avantageuses qu'un traitement PHP. Je répète qu'un SGBD est optimisé pour ce genre de traitement.

A chaque fois que j'ai les données de plusieurs tables à mettre en corrélation, je fait toujours une étude de volumétrie et un petit bench pour déterminer la solution la plus adaptée.

Je soutiens à nouveau que, dans beaucoup de cas, une jointure est moins gourmande qu'un traitement PHP

C'est interressant mais comment fait tu ton bench ?
je développe mon application e-commerce et je n'utilise pas une seule jointure.
J'ai commencé ce travail sur un code basique avec le panier de base fonctionnel.
Je n'est plus qu'à modifier quelques fonctions, pour amélioré le programme
exemple:

function insert_category($catname)
//insertion d'une nouvelle catégorie
{
   include ("connexion.php");
   // Vérification que les catégories n'existe pa déjà
   $query = "select *
             from categories
             where catname='$catname'";
   $result = mysql_query($query);
   if (!$result || mysql_num_rows($result)!=0)
     return false;

   // insert new category 
   $query = "insert into categories values
            ('', '$catname')"; 
   $result = mysql_query($query);
   if (!$result)
     return false;
   else
     return true;
}

Le travail est essentiellement fait sur les index, et coder entièrement en fonction.
Le code entier est d'une bonne efficiente c'est très agréable à la lecture.
http://courant-alternatif.org/test_connexion/index.php

Où as-tu besoin de jointure dans cet exemple ?

Mes bench, c'est :
j'écris une série de requête/petit script pour charger les données
Je crée des jeux de test de différents volume
J'exécute des tests sur la plateforme de pré-production
J'en déduit une courbe de performance que je met en relation avec les études de volumétrie et j'en déduit le code à utiliser.

C'est comme ça que j'ai remarqué que, pour des tables immenses, il vaut mieux des tableaux de 4Go en mémoire via PHP qu'une jointure.

Et c'est aussi comme ça que, la plupart du temps, avec un index bien pensé, une jointure est beaucoup plus performante qu'autre chose.

Le seul code que j'ai tendance à mettre de côté sans chercher à voir plus loin, c'est le récursif car, d'expérience, c'est un gouffre à performance.