Est-il stupide d'écrire un programme de traitement par lots volumineux entièrement en PL / SQL?

Question

Je commence à travailler sur un programme qui est peut-être le plus naturellement décrit comme un lot de calculs sur des tables de base de données et qui sera exécuté une fois par mois. Toutes les entrées sont dans les tables de base de données Oracle et toutes les sorties seront dans les tables de base de données Oracle. Le programme devrait rester maintenable pendant de nombreuses années.

Il semble simple d'implémenter cette solution sous la forme d'une série de procédures stockées, chacune effectuant une transformation rationnelle, par exemple une répartition des coûts entre services selon certaines règles commerciales. Je peux ensuite écrire des tests unitaires pour vérifier si le résultat de chaque transformation est conforme aux attentes.

Est-ce une mauvaise idée de faire tout cela en PL / SQL? Préférez-vous effectuer des calculs de lots lourds dans un langage de programmation orienté objet typique, tel que C #? N'est-il pas plus expressif d'utiliser un langage de programmation centré sur la base de données, tel que PL / SQL?

Answer 1

Normalement, je dis de mettre le moins possible en PL / SQL - il est généralement beaucoup moins facile à gérer - lors de l’un de mes derniers emplois, j’ai vraiment vu à quel point il était difficile et difficile de travailler avec.

Cependant, comme il s’agit d’un traitement par lots - et puisque l’entrée et la sortie sont toutes les deux une base de données - il est judicieux de placer la logique dans PL / SQL - afin de minimiser les "pièces mobiles". Toutefois, s’il s’agissait d’une logique d’entreprise - ou de composants utilisés par d’autres composants de votre système -, je vous prierais de ne pas le faire.

Answer 2

Vous décrivez les conditions suivantes

a) Doit pouvoir implémenter le traitement par lots b) Le résultat doit être maintenable

Ma réponse:

1. PL / SQL a été conçu pour réaliser exactement ce que vous décrivez. Il est également important de noter que l'efficacité de PL / SQL n'est pas disponible dans d'autres outils. Une langue de procédure stockée place le traitement à côté des données - c’est à cet endroit que le traitement par lots doit être effectué.
2. Il est assez facile d'écrire du code mal gérable dans toutes les langues.

Cela dit, votre mise en œuvre dépendra des compétences disponibles, d'une conception appropriée et du respect de processus de bonne qualité.

Pour être efficace, votre implémentation doit traiter les données par lots (sélectionner des lots et insérer / mettre à jour par lots). Le danger avec une approche orientée objet est qu’il est facile de s’orienter vers une conception qui traite les données ligne par ligne. Ce type d’approche entraîne une surcharge inutile et sera nettement moins efficace qu’une conception qui traite des données par lots de lignes.

Il est possible d'utiliser les deux approches avec succès.

Mathew Butler

Answer 3

Ce que les autres commentateurs noteront - la question concerne PL / SQL, pas SQL. Certaines des réponses ont évidemment porté sur SQL, pas PL / SQL. PL / SQL est un langage de base de données entièrement fonctionnel et mature. Il y a quelques lacunes, mais pour le type de chose que l'affiche veut faire, c'est très bien.

Answer 4

Non, ce n'est pas nécessairement une mauvaise idée. Si la solution vous semble simple et vous permet de tester et de vérifier chaque processus, cela semble être une bonne idée. Les plates-formes OO peuvent être (bien que cela ne soit pas obligatoire) pour des ensembles de données volumineux, car la création d'objets et les frais généraux peuvent réduire les performances.

Oracle a conçu PL / SQL avec des problèmes comme le vôtre à l’esprit. Si la connaissance de la base de données et de PL / SQL au sein de l’entreprise est suffisante, cela semble une solution raisonnable. Gardez à l'esprit les ensembles de lots volumineux, car chaque appel de PL / SQL au moteur SQL réel est un commutateur de contexte. Par conséquent, les processus d'enregistrement unique doivent être regroupés dans la mesure du possible pour améliorer les performances.

Answer 5

Assurez-vous simplement de consigner ce qui se passe pendant que vous travaillez. Sinon, vous aurez une boîte noire et si elle reste bloquée quelque part pendant des heures, vous vous demanderez si vous devez l'arrêter ou la laisser fonctionner «un peu plus».

Answer 6

PL / SQL est un langage mature qui s’intègre parfaitement à SQL. Avec chaque version d'Oracle, il devient de plus en plus puissant. Également à partir d'Oracle 11, PL / SQL est compilé par défaut en code machine.

Answer 7

J'ai écrit un grand nombre de programmes de traitement par lots et de génération de rapports à la fois en PL / SQL et en Pro C pour un projet. Ils préféraient en général que j’écrive en PL / SQL, car leurs propres développeurs, qui, à l’avenir, jugeraient qu’il était plus facile à comprendre que le code Pro C.

En fin de compte, il s’agissait uniquement du traitement ou des rapports vraiment funky écrits en Pro * C.

Il n'est pas nécessaire d'écrire ces procédures en tant que procédures stockées, comme d'autres personnes l'ont déjà mentionné. Il peut s'agir simplement de fichiers de script exécutés si nécessaire, un peu comme un script shell. Facilitez également le contrôle de la révision du code source et la migration entre les systèmes de test et de production.

Answer 8

Tant que les calculs que vous devez effectuer peuvent être capturés de manière adéquate et lisible en PL / SQL, utiliser uniquement PL / SQL vous semblerait plus logique.

La difficulté réside dans la maintenabilité - il est très facile d’écrire du SQL non maintenable, ne serait-ce que parce que chaque SGBDR a une syntaxe différente et un ensemble de fonctions différent une fois que vous sortez du simple langage DML SQL, et qu’il n’ya pas de véritable standard de formatage. commentant, etc.

Answer 9

J'ai créé des programmes batch utilisant C # et SQL.

Avantages de C #:

Vous disposez de la bibliothèque complète de .NET et de toute la puissance d'un langage OO.

Contre de C #:

* Programme de traitement par lots et db séparés - cela signifie que vous devrez gérer votre programme de traitement par lots séparément de la base de données.

* Vous devez échapper à tout ce code SQL.

Avantages de SQL:

* s'intègre parfaitement au SGBD. Si ce travail ne fait que manipuler la base de données, il serait logique de l'inclure à la base de données. Vous vous retrouvez avec une seule base de données et tous ses composants dans un seul package.

* Pas besoin d'échapper au code SQL

* garder les choses réelles - vous programmez dans votre domaine problématique

Contre de SQL:

Son code SQL et moi, personnellement, je ne le connais pas aussi bien que SQL.

En général, je préférerais utiliser SQL à cause des avantages décrits ci-dessus.

Answer 10

Ceci est une question chargée :) Il y a quelques conceptions d'architecture de programmation de base de données que vous devriez connaître, ainsi que leurs coûts / avantages. 2 Niveau signifie généralement qu'un client se connecte à une base de données et émet des appels SQL directs. 3 tiers signifie généralement que vous disposez d'un "serveur d'application". qui émet des appels SQL directs vers la base de données, mais le client communique avec le serveur d'applications. En règle générale, cela permet de "mettre à l'échelle". Enfin, vous avez des applications à deux niveaux et demi qui utilisent un format similaire à deux niveaux. Seul le travail est compartimenté dans les procédures stockées.

Votre processus ressemble à un "back office". Les clients / processus ont simplement besoin de résultats qui sont agrégés et mis en cache une fois par mois. Autrement dit, aucun agent ne se connecte et se connecte souvent et dit "effectue ces calculs". Au lieu de cela, vous évoquez un processus qui se produit de temps en temps et vous pouvez vous en sortir en temps non réel.

Par conséquent, étant donné ces exigences, je dirais qu'en général, il sera plus rapide de se rapprocher des données et de laisser SQL Server effectuer tous les calculs. Je pense que vous constaterez que la proximité des données vous sera utile.

Cependant, en effectuant ces calculs, vous constaterez peut-être que certains calculs ne sont pas applicables aux serveurs SQL. Prenons par exemple le calcul des intérêts courus d'une obligation ou de tout instrument à revenu fixe. Pas très joli en SQL, et bien plus adapté à un langage de programmation plus riche. Toutefois, si vous ne disposez que de moyennes simples et d’autres agrégats relativement sains, je me contenterais des procédures stockées, du côté SQL.

Encore une fois, il n’ya pas assez d’informations sur la nature de vos calculs, ni sur ce que votre maison exige en termes de capacités de développement de SQL pour le support, ou sur ce que votre patron dit ... mais comme je connais bien SQL, et tiens à rester proche des données, je resterais pur SQL / procédures stockées pour une tâche comme celle-ci.

YMMV:)

Answer 11

Cela n’est généralement pas plus expressif, car la plupart des langages de procédures stockées craignent par leur conception. Mais il sera probablement plus rapide que dans une application externe.

Je suppose que cela se résume à votre familiarité avec PL / SQL, à combien de temps vous avez pour écrire ceci, à quelle importance les performances sont importantes et si vous pouvez raisonnablement vous attendre à ce que les mainteneurs soient suffisamment familiarisés avec PL / SQL pour maintenir une grande programme écrit dedans.

Si la vitesse n'est pas pertinente et que les responsables ne seront probablement pas compétents en PL / SQL, il vaut peut-être mieux utiliser un langage "traditionnel".

Vous pouvez également utiliser une approche hybride, où vous utilisez PL / SQL pour générer des données intermédiaires (par exemple, des jointures et des sommes de table ou autre) et une application distincte pour contrôler le flux et vérifier les valeurs et les erreurs.