La commande SQL offre contrôle et performance maximum mais exige de maîtriser le SQL ; l'interface graphique est plus simple et suffit dans la plupart des cas — voici comment choisir. L'INTERFACE graphique (sélection de tables + liens) : (1) On choisit des tables, on définit les liens (jointures) visuellement, et Crystal GÉNÈRE la requête SQL sous le capot. (2) Avantages : ACCESSIBLE (pas besoin de connaître le SQL), visuel, rapide pour des rapports standards, facile à maintenir (on modifie via l'interface). (3) Convient pour : la majorité des rapports — tables reliées par des clés, filtres simples, regroupements via l'interface. C'est le choix par défaut. La COMMANDE SQL (requête écrite à la main) : (1) On écrit soi-même le SELECT/FROM/WHERE/JOIN, qui devient la source. (2) Avantages : CONTRÔLE TOTAL (jointures exactes, filtres, calculs côté base), possibilité de requêtes COMPLEXES (sous-requêtes, UNION, agrégations SQL, fonctions spécifiques à la base) impossibles ou pénibles via l'interface, et PERFORMANCE optimale (on pousse le maximum de travail à la base, on ne rapatrie que le nécessaire). (3) Convient pour : les cas complexes ou exigeants — requêtes élaborées, performance critique sur gros volumes, logique que l'interface ne permet pas. (4) Inconvénients : exige de MAÎTRISER le SQL, c'est du CODE à maintenir (moins accessible que le glisser-déposer), et une requête mal écrite peut être lente ou fausse. Quand écrire une COMMANDE SQL : (1) Requête COMPLEXE que l'interface ne gère pas bien : sous-requêtes, UNION (combiner plusieurs SELECT), agrégations avancées, fonctions SQL spécifiques, logique de jointure élaborée. (2) PERFORMANCE critique : pour pousser jointures, filtres et agrégations vers la base (optimisée) et minimiser les données rapatriées — décisif sur de gros volumes. (3) CONTRÔLE précis nécessaire sur la requête (le SQL exact exécuté). (4) Réutiliser une requête SQL EXISTANTE et éprouvée. Quand rester sur l'INTERFACE : (1) Rapport STANDARD (tables reliées, filtres simples). (2) Vous ne maîtrisez PAS le SQL. (3) Vous voulez la SIMPLICITÉ et une maintenance facile. (4) L'interface suffit à produire ce que vous voulez. Comment décider : (1) L'interface répond au besoin et vous voulez la simplicité → INTERFACE (par défaut). (2) Besoin de complexité (sous-requêtes, UNION…), de performance maximale, ou de contrôle précis, ET vous maîtrisez le SQL → COMMANDE SQL. (3) En cas de doute, commencez par l'interface ; passez à la commande SQL seulement si vous butez sur une limite (complexité, performance). Bonnes pratiques pour une commande SQL : (1) Écrivez une requête VALIDE et OPTIMISÉE (bonnes jointures, filtres côté base, index exploités). (2) Intégrez des PARAMÈTRES Crystal pour le filtrage interactif (poussé côté serveur). (3) TESTEZ le résultat (justesse) et la performance. (4) Documentez la requête (c'est du code à maintenir). En résumé : utilisez l'INTERFACE graphique par défaut (accessible, simple, suffisante pour la plupart des rapports) ; écrivez une COMMANDE SQL quand vous avez besoin de requêtes COMPLEXES (sous-requêtes, UNION, agrégations), d'une PERFORMANCE maximale (pousser le travail à la base) ou d'un CONTRÔLE précis — et que vous MAÎTRISEZ le SQL. La commande SQL est puissante (contrôle, performance) mais exige des compétences SQL et de la rigueur (code à maintenir, requête à optimiser). Choisissez selon la complexité du besoin et vos compétences : simple et standard → interface ; complexe/performant → commande SQL.

Combiner plusieurs sources dépend de leur nature : si elles sont dans la même base, on les joint ; si elles sont dans des sources DIFFÉRENTES non jointables, les sous-rapports sont souvent la meilleure solution — voici les approches et leurs limites. Cas 1 — les tables sont dans la MÊME base : (1) Utilisez des JOINTURES classiques (niveau 0) : sélectionnez les tables, reliez-les par leurs clés. La base combine tout en une requête (performant). (2) Ou une COMMANDE SQL (4-4) pour un contrôle/une performance maximum sur des jointures complexes. C'est le cas le plus simple : une seule connexion, des jointures. Cas 2 — les données viennent de SOURCES DIFFÉRENTES (deux bases distinctes, une base + un fichier Excel, une base + une source SAP) qui ne peuvent PAS être jointes directement par la base : (1) SOUS-RAPPORTS (approche recommandée, niveau 4-1) : chaque source dans son propre rapport (le principal sur la base A, un sous-rapport sur la base B ou le fichier). On LIE le sous-rapport au principal par un champ commun (le sous-rapport affiche les données correspondantes de l'autre source). C'est souvent la meilleure façon de combiner des sources hétérogènes proprement. Attention à la performance (placer le sous-rapport lié au niveau d'un groupe, pas des détails). (2) Multi-connexions dans un même rapport : Crystal permet d'ajouter plusieurs connexions et de tenter de lier des tables de sources différentes. MAIS les jointures INTER-SOURCES ne peuvent pas être faites par une seule base : Crystal doit rapatrier les données des deux sources et les combiner CÔTÉ CLIENT — ce qui peut être LENT et lourd sur des volumes importants. À utiliser avec prudence, sur des volumes modérés. (3) Préparer les données en amont : parfois, la meilleure solution est de ne PAS tout faire dans Crystal — consolider les données dans une base/vue intermédiaire (via un ETL, une vue de base de données, une table de synthèse) puis brancher Crystal sur cette source unique. Cela déporte la complexité vers la base (performant, maintenable) et simplifie le rapport. Comment choisir : (1) MÊME base → jointures (ou commande SQL). (2) Sources différentes, besoin d'afficher des données correspondantes → SOUS-RAPPORTS liés (recommandé, en soignant la performance). (3) Sources différentes, volumes modérés, jointure simple → multi-connexions (avec prudence, jointures côté client). (4) Combinaison complexe/récurrente ou gros volumes → CONSOLIDER en amont (vue/table intermédiaire) puis un rapport sur source unique — souvent la solution la plus robuste et performante. Les points d'attention : (1) Performance : les combinaisons inter-sources (sous-rapports liés dans les détails, multi-connexions côté client) peuvent être coûteuses — préférez le niveau groupe pour les sous-rapports, limitez les données, ou consolidez en amont. (2) Cohérence des données : combiner des sources suppose des clés communes fiables et des données cohérentes (mêmes identifiants). (3) Maintenance : plus il y a de sources et de mécanismes (sous-rapports, connexions multiples), plus le rapport est complexe à maintenir. En résumé : combinez plusieurs sources selon leur nature — JOINTURES (ou commande SQL) si elles sont dans la MÊME base ; SOUS-RAPPORTS liés (approche recommandée, en soignant la performance) pour des sources DIFFÉRENTES non jointables ; multi-connexions possible mais coûteux (jointures côté client) ; et pour les cas complexes ou volumineux, CONSOLIDER les données en amont (vue/table intermédiaire) puis brancher un rapport sur cette source unique — souvent le plus robuste. Choisissez en fonction de la jointabilité des sources, du volume et de la performance visée. Combiner des sources hétérogènes est un besoin réel mais délicat ; les sous-rapports et la consolidation en amont sont les approches les plus fiables.