Question

Dans l'ancien temps, nous avons utilisé pour accéder à la base de données via des procédures stockées. Ils étaient considérés comme façon `mieux » de la gestion des données. Nous gardons les données dans la base de données, et toute langue / plate-forme peut y accéder via JDBC / ODBC / etc.

Cependant, ces dernières années de réflexion en temps marche / méta-données basées mécanismes de récupération de stockage tels que Hibernate / DataNucleus sont devenus populaires. Au départ, nous étions inquiets qu'ils seraient lents à cause des étapes supplémentaires impliquées (réflexion est cher) et la façon dont ils extraient les données inutiles (l'objet entier) quand tout nous avons besoin est un champ.

Je commence à planifier un grand projet d'entreposage de données qui utilise J2EE, mais je suis un peu incertain il faut aller pour les procédures stockées ou JDO / JPA et autres. Récemment, je travaille avec Hibernate, et pour être tout à fait 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 les requêtes)
. - Il y a probablement plus d'un millier de procédures stockées: ajouter, supprimer, mettre à jour, getById, etc, pour chaque table

JDO
+ Je ne vais pas passer les prochains mois à écrire parameters.add ( « @ prénoms », customer.getFirstName ()); ...
- sera plus lente que SPs (mais la pagination plus de soutien)

Que feriez-vous pour repulper dans ma situation. Dans ce cas, je pense qu'il est c'est pareil.

Merci,

John

Pas de solution correcte

Autres conseils

"JDO - sera plus lente que SPs (mais la pagination plus de soutien)"

Cette hypothèse est souvent fausse. Il n'y a aucune raison pour les SP pour être particulièrement rapide. Je l'ai fait quelques mesures et ils sont pas plus rapide que le code en dehors de la base de données.

Un entrepôt de données est caractérisée par des charges d'insertion seule et requêtes SELECT...GROUP BY... de longue durée.

Vous n'êtes pas écrire le traitement transactionnel OLTP. Vous n'utilisez 3NF comme un moyen d'éviter les anomalies de mise à jour sur la mise à jour / suppression des transactions.

Depuis que vous faites les insertions en bloc, un SP sera certainement plus lent qu'un utilitaire de chargement en vrac. chargeurs en vrac sont souvent multi-thread et consommeront toutes les ressources CPU disponibles. La SP fait partie de la base de données et ne peut partager des ressources limitées DB.

Puisque vous êtes surtout faire SELECT GROUP BY, un SP ne va pas aider beaucoup ici, que ce soit. L'instruction SELECT ne bénéficie pas d'être enveloppé dans une procédure.

Vous ne les avez pas besoin. Ils ne contribuent pas.

Vous pouvez comparer facilement une masse à vide et une requête pour démontrer ne sont pas aider de ce SP.

Rod Johnson dans sa "conception J2EE adn développement" a écrit une analyse très claire sur ORM / StoredProcedures. Il a dit que

  

Les procédures stockées ne doivent être utilisés dans un système J2EE pour effectuer des opérations qui utilisera toujours la base de données fortement, si elles sont mises en œuvre dans la base de données ou dans le code Java qui échange beaucoup de données avec la base de données.

Comme vous avez l'intention de mettre en œuvre un datawarehouse, je pense que l'approche des procédures stockées est le bon choix.

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 de performance de l'utilisation des outils de charge spécialisés et peut-être des procédures stockées (si vous utilisez une base de données suffisamment ancienne). En outre, vous finirez probablement le codage manuel au moins une partie SQL. Avoir vos scripts génériques faites comme vous stockés procs permettra de programmer tous de la même manière et ne pas avoir à se soucier de changer la façon dont ils sont invoqués lorsque vous repassez code généré pour le faire fonctionner mieux.

En ce qui concerne l'obtention des données sur, si ce que vous construisez dans J2EE est un outil de reporting, alors vous pouvez être mieux d'utiliser JDO. Bien que je ne suis pas terriblement familier avec le côté des rapports des choses, un avantage que je peux voir est qu'il sera plus facile de permettre à vos utilisateurs finaux de faire des rapports personnalisés que vous n'avez pas prévu à l'avance (même si vous avez encore avoir certaines limites à ce qu'ils peuvent faire pour qu'ils ne prennent pas sur la base de données dans le processus).

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top