Exécution de requêtes SQL statiques contre DB2 sans pureQuery

Question

Je voudrais utiliser JPA sur JDBC pour une nouvelle application. Je suis strictement à l'aide des requêtes nommées et les méthodes de base CRUD de gestionnaire JPA entité, ce qui me permet (avec l'aide de mise en veille prolongée, ou tout autre implémentation JPA) pour extraire toutes les requêtes SQL natives qui seront effectuées sur la base de données. Avec cette liste de requêtes statiques, je comprends que je peux construire un package DB2 qui est de tous les plans d'exécution de mes demandes.

Alors ma question est: Est-ce l'exécution de ces requêtes via JDBC contre DB2 tirer parti de ces plans d'exécution, ou non? Je comprends que le produit pureQuery peut capturer la liste des commandes SQL. Est-ce, toujours via JDBC et non via l'API spécifique pureQuery, fournir plus? une telle fonctionnalité de liaison statique DB2 spécifique? ou il est équivalent à JDBC?

Merci pour tout morceau de réponse.

Answer 1

Les applications JDBC exécutent uniquement SQL dynamiques (DB2 n'utilise pas les paquets statiques).

Il n'y a que deux façons d'obtenir SQL statique (où les requêtes sont stockées dans un package dans la base de données): Écrivez votre application à l'aide SQLJ (qui élimine JPA / Hibernate) ou utiliser pureQuery (qui se trouve entre JDBC et la base de données) .

Gardez à l'esprit que même avec SQL dynamique, DB2 ne cache les plans d'exécution des requêtes, si elles sont exécutées assez souvent (à savoir, ils restent dans le cache), alors vous ne verrez pas les frais généraux de la compilation de la requête. Le cache est utile que si les requêtes sont une correspondance exacte octet par octet, donc select * from t1 where c1 = 1 n'est pas la même chose que select * from t1 where c1 = 2, ni select * from t1 where C1 = 1 (qui donne le même résultat, mais la requête est différente). En utilisant des marqueurs de paramètres (select * from t1 where c1 = ?) est la clé. Votre DBA peut régler la taille du cache de catalogue pour aider à maximiser le taux de succès sur ce cache.

Bien que la mise en cache permet d'éviter la compilation à plusieurs reprises une requête, il ne propose pas la stabilité du régime qui ne SQL statique, YMMV.