SQL Developer ou Toad ?

fadace

Développement Oracle SQL/PL-SQL : SQL Developer ou Toad… lequel choisir ? ♪

- Titre : SQL Developer ou Toad ?

- Auteur : fadace

- Parution : 14 août 2008

- Mise à jour : 15 août 2008

- Licence : Copyright ® 2008 Fabien Celaia. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- II. Analyse

- II-A. Prix et stratégie de développement

- II-B. Export Excel

- II-C. Ressources

- II-D. Traitements sur Recordsets

- II-E. Convivialité de l'interface graphique

- II-F. Persistance des sessions

- II-G. Plans d'exécution

- II-H. Monitoring de sessions

- II-I. Compilations multiples

- II-J. Recherche

- II-K. Rétrogénération

I - Introduction

Voilà un peu plus de deux ans, Oracle livrait enfin un éditeur SQL/Pl-SQL « acceptable », sous le nom de code de Raptor : SQL Developer était donc né.

Avant ce produit, seul sqlplus, ou éventuellement sqlplusw (une très pauvre version en ANSI) était livré avec la base Oracle. Les clients étaient donc contraints de passer une nouvelle fois à la caisse pour acquérir des licences d'outils tels que Embarcadero ou Toad, après que celui-ci a été repris par Quest. Il existait bien déjà des éditeurs open source, de type SQuirel, mais ils étaient ingérables si on souhaitait développer en PL-SQL.

SQL Developer offre donc une alternative gratuite aux éditeurs commerciaux. Il va sans dire qu'il ne rivalise pas encore totalement avec les outils susmentionnés, mais au fil des versions et des plug-ins, son choix peut s'avérer profitable, puisqu'il est gratuit.

Certains utilisateurs, rebutés par les premières versions de SQL Developer, ou fermement attachés à leur version de Toad, s'escriment à ne trouver à SQL Developer que des défauts.

Ce petit article qui, je l'espère, s'étoffera avec les expériences que vous voudrez bien me faire partager n'est pas un comparatif à proprement parler. Il reprend juste quelques assertions/préjugés souvent entendues (elles apparaissent à droite du logo avec un I) et tentent de démontrer leur bien-fondé.

Les outils ainsi comparés sont Toad Base de Quest, version 9.6.1 et SQL Developer version 1.5.1 d'Oracle.

En l'état, il va sans dire que Toad a une richesse fonctionnelle supérieure à SQL Developer. Reste à savoir si cette plus-value vaut le prix qu'elle coûte pour tous vos développeurs… ou si ceux-ci peuvent se satisfaire de SQL Developer, vous permettant ainsi des économies de licences substantielles…

II - Analyse

II-A - Prix et stratégie de développement

Toad 9.6.1 est un produit Quest vendu, prix catalogue, $870/per seat pour sa version de base. Il faut ajouter $810/per seat pour le module DBA.

Oracle SQL Developer 1.5.1 est un produit Freeware développé par Oracle d'une part, et en ce qui concerne les plug-ins, par des communautés de développeurs. Bien que quelques modules permettent de traiter certains aspects DBA, il n'a pas pour vocation de passer « sous » la couche logique de la base. Pour l'administration à proprement parler, c'est Oracle Grid/DB Control qui est l'outil adéquat.

II-B - Export Excel

Lorsque l'on désire exporter le résultat d'une requête vers Excel par ex. SQL Developer réexécute la requête. Donc si l'on désire exporter le résultat d'une requête qui dure 2 h, il faut d'abord la lancer une fois, puis faire l'export qui va la relancer encore une fois, soit 4 heures d'attente. Avec TOAD une fois la requête exécutée, on peut exporter les données sans une nouvelle exécution.

L'export de données vers Excel en passant par le presse-papier ne fonctionne pas, il faut toujours passer par un fichier sauvegardé sur le disque puis l'ouvrir dans Excel. Ceci amène une lourdeur lorsqu'on a plusieurs requêtes à exporter dans un seul et unique document.

Le copier/coller de la Grid dans Excel marche correctement.

Si le recordset est trop important pour passer en mémoire (c'est le cas lorsque le Export Data via presse-papier semble planter), il est possible de l'exporter sous Excel sans réexécuter la requête, exactement comme sous Toad (ce sont là des propriétés de l'objet grid Java). Il y a par contre quelques limitations : les colonnes doivent être clairement définies sans ambiguïté.

Lors de l'export, le résultat d'une requête de type

select a.dummy, b.dummy from dual a, dual b

retournera lors de l'export

Ce qui ne sera plus le cas si la requête est écrite ainsi

select a.dummy A, b.dummy B from dual a, dual b

II-C - Ressources

Oracle SQL Developer consomme plus de ressources sur la machine client.

Comme tout programme travaillant avec une JVM, SQL Developer est plus gourmand en mémoire sur le poste client. Par contre, il nécessite moins de connexions serveur gourmandes en RAM sur le serveur Aix (PGA), ce qui est un plus. La différence n'est pas si flagrante que cela cependant lors de l'exécution de requêtes

Il reste cependant que Toad.exe relâche ensuite la mémoire et que la JVM la garde allouée. Un utilisateur qui ne ferait qu'ouvrir des connexions sans jamais refermer son programme verra alors son utilisation mémoire enfler sur SQL Developer.

La problématique de la mémoire excessive sur le serveur (un onglet de connexion Toad équivaut à un processus serveur) pourrait être résolue en bridant le nombre de connexions simultanées autorisées par développeur au niveau d'un profile Oracle.

II-D - Traitements sur Recordsets

Lorsque l'on travaille dans une vue data browser et que l'on met des filtres pour visualiser les données Toad conserve les filtres, ce qui n'est pas le cas de Oracle SQL Developer.

Avec SQL Developer, il est possible de filtrer, mais le filtre ne reste pas par défaut. Dans ce cas, mieux vaut utiliser une requête. Un filtre sur le databrowser se pose après coup sur le recordset : on a donc remonté sur la machine cliente toutes les données, et c'est sur ce dataset que le filtre est appliqué.

Il est plus judicieux de le faire via la requête puisque celle-ci ne remonte alors que les données strictement utiles du serveur. Si par conte, il s'agit de trier ou filtrer sur une grosse requête complexe déjà exécutée, la notion de filtre et de tri de SQL Developer est similaire (traitement du recordset).

Avec SQL Developer, lors de gros output, le recordset est affiché dès les premières lignes paginées. Avec Toad, il faut attendre la fin du traitement pour accéder aux données.

II-E - Convivialité de l'interface graphique

Seul Toad permet de paralléliser des sessions et, ainsi, de pouvoir comparer aisément des outputs en passant d'un tab à un autre aisément.

Cette option fort appréciée sous Toad existe aussi sous SQL Developer.

Dès la v.1.5.1, l'exécution d'une longue requête ne gèle plus les autres sessions. Il reste cependant des exceptions mal gérées, mais ceci sur les deux produits.

Exemples

1. Un rafraîchissement des statistiques d'une table sur SQL Developer gèle totalement l'environnement pendant son traitement.

2. Une requête un peu importante refuse de s'annuler sur Toad.

3. Etc.

La vision des objets par onglet chez Toad est plus conviviale que l'arbre de SQL Developer.

Il s'agit là avant tout de goût et d'habitude à prendre.
Avec SQL Developer et son arborescence d'objets, il faut réfléchir par schéma, puis par type d'objet.
Avec Toad, on se focalise d'abord sur un type d'objet, puis on filtre par schéma…

Avec Peoplesoft HR (40 000 objets dans un seul schéma), Toad amènera peut-être un avantage.
Avec eBusiness Suite (des centaines de modules et donc autant de schémas différents), on préférera peut-être SQL Developer pour sa capacité à se focaliser sur un module.

II-F - Persistance des sessions

Avec SQL Developer, à la fermeture, il faut éventuellement passer par une demande d'acceptation si l'on souhaite garder ses requêtes et si les sessions n'ont pas eu un fichier associé précédemment…

Elles seront par contre rouvertes automatiquement à la prochaine ouverture de SQL Developer… sans être toutefois rattachées à une session (ce qui se fera via le premier appel à la requête).

C'est exactement le même cas avec Toad, en moins pratique puisqu'il ouvre une combo par session ouverte.

À la réouverture cependant, Toad ne rouvre pas automatiquement ces requêtes sauvées.

II-G - Plans d'exécution

La lecture des plans d'exécution est meilleure avec TOAD.

C'est une question d'habitude : il n'y a pas grand changement puisque les données viennent de la même source (optimiseur Oracle). La cardinalité ajoutée au niveau Toad vient de données statistiques, donc est de toute façon sujette à caution… mais c'est pratique il est vrai…

plan avec SQL Developer

plan avec Toad

II-H - Monitoring de sessions

Toad permet de monitorer les sessions et de les supprimer au besoin, sans risquer de supprimer la mauvaise session.

Cette possibilité intégrée à Toad depuis longtemps a été ajoutée à la version 1.5.1 de SQL Developer via le menu Outils -> Monitor Sessions

II-I - Compilations multiples

Toad permet de compiler plusieurs objets invalides à la fois. Avec SQL Developer, il faut passer sur chaque objet.

SQL Developer permet, via le menu conceptuel sur le type d'objet compilé, de recompiler tous les objets invalides… ou tous les objets.

II-J - Recherche

Rechercher une chaîne de caractères dans tous les objets de la BD (dans les Tables, Packages, Procédures, fonctions, index, contraintes…) n'est possible qu'avec Toad.

Cette option existe aussi sous SQL Developer, mais elle se situe au niveau des rapports : Visualiser -> Reports -> Data Dictionary Reports -> PL/SQL -> Search Source Code

II-K - Rétrogénération

L'extraction de scripts DDL ne fonctionne pas toujours correctement avec SQL Developer.

Toad génère non seulement l'objet, mais ses droits associés.

SQL Developer ne génère que l'objet associé, sans ses droits.