Procédures stockées vs JDO pour le projet d'entrepôt de données

Question

Autrefois, nous accédions à la base de données via des procédures stockées. Ils étaient considérés comme la meilleure façon de gérer les données. Nous gardons les données dans la base de données, et n'importe quelle langue/plateforme peut y accéder via JDBC/ODBC/etc. Cependant, ces dernières années, les mécanismes de récupération de stockage à base de méta-données/de réflexion à l'exécution tels que Hibernate/DataNucleus sont devenus populaires. Au départ, nous avions peur qu'ils soient lents à cause des étapes supplémentaires (la réflexion est coûteuse) et de la façon dont ils récupèrent des données inutiles (l'objet entier) alors que tout ce dont nous avons besoin est un seul champ.

Je commence à planifier un grand projet d'entreposage de données qui utilise J2EE, mais je ne sais pas si je devrais utiliser Stored Procedures ou JDO/JPA et autres. Récemment, j'ai travaillé avec Hibernate, et pour être honnête, je ne manque pas d'écrire des procédures stockées CRUD!

Il se résume essentiellement à:

Procédures stockées
+ peut être optimisé sur le serveur (bien que seules les requêtes)
- Il y a probablement plus d'un millier de procédures stockées: ajouter, supprimer , mise à jour, getById, etc, pour chaque table.

JDO
+ je ne vais pas passer les prochains mois à écrire parameters.add ("@ prénoms", customer.getFirstName()); ...
- Sera plus lent que les SP (mais la plupart prend en charge la radiomessagerie)

Que feriez-vous dodu dans ma situation. Dans ce cas, je pense que c'est beaucoup de beaucoup.

Merci,

John

Answer 1

Johnson Rod dans sa "conception J2EE adn développement" a écrit une analyse très claire sur ORM/StoredProcedures. Les procédures stockées ne doivent être utilisées que dans un système J2EE pour effectuer des opérations qui utiliseront toujours la base de données, qu'elles soient implémentées dans la base de données ou dans un code Java qui échange beaucoup de données avec la base de données. base de données. Comme vous prévoyez d'implémenter un datawarehouse, je pense que l'approche des procédures stockées est le bon choix.

Answer 2

"JDO - sera plus lente que SPs (mais plus grand soutien radiomessagerie)"

Cette hypothèse est souvent fausse. Il n'y a aucune raison pour que SP soit particulièrement rapide. J'ai fait quelques mesures et elles ne sont pas plus rapides que du code en dehors de la base de données.

Un entrepôt de données est caractérisé par des charges insérées uniquement et des requêtes SELECT...GROUP BY... de longue durée.

Vous n'écrivez pas de traitement transactionnel OLTP. Vous n'utilisez pas 3NF pour empêcher les anomalies de mise à jour lors des opérations de mise à jour/suppression.

Puisque vous faites des insertions en vrac, un SP sera certainement plus lent qu'un utilitaire de chargement en vrac. Les chargeurs en bloc sont souvent multithread et consomment toutes les ressources CPU disponibles.Le SP fait partie de la base de données et ne peut partager que des ressources de base de données limitées.

Puisque vous faites la plupart du temps SELECT GROUP BY, un SP ne sera pas utile ici non plus. L'instruction SELECT ne bénéficie pas d'être enveloppé dans une procédure.

Vous n'en avez pas besoin. Ils n'aident pas.

Vous pouvez facilement comparer une charge en bloc et une requête pour démontrer que les SP ne vous aident pas.

Answer 3

Je suggère d'utiliser les métadonnées pour générer les scripts que vous utilisez pour le chargement dans l'entrepôt de données. Cela vous permet d'obtenir des avantages en termes de performances en utilisant des outils de chargement spécialisés et peut-être à partir de procédures stockées (si vous utilisez une base de données suffisamment ancienne). En outre, vous finirez probablement par coder à la main au moins un peu de SQL. Le fait de faire vos scripts génériques en tant que proc stockés vous permettra de les planifier tous de la même manière et de ne pas avoir à vous soucier de changer la façon dont ils sont invoqués lorsque vous réécrivez du code généré pour le faire fonctionner mieux. En ce qui concerne l'extraction des données, si ce que vous construisez dans J2EE est un outil de création de rapports, il vaut mieux utiliser JDO. Même si je ne suis pas très familier avec les rapports, un avantage que je peux constater est qu'il sera plus facile de permettre à vos utilisateurs finaux de faire des rapports personnalisés que vous n'aviez pas anticipés (même si vous devez encore avoir certaines limites sur ce qu'ils peuvent faire pour qu'ils ne retirent pas la base de données dans le processus).