J'ai trouvé un article de 2008 discutant de la référence à Call Java code de MySQL . Il y avait beaucoup de mises en garde et de non-responsabilité, car le processus impliquait de travailler avec une branche expérimentale de MySQL.
Pour un projet, j'ai à l'esprit, il serait très utile d'être en mesure d'accéder aux bibliothèques Java au sein de MySQL, analogue à la Procédures stockées Java . Cette capacité existe-t-elle maintenant comme une caractéristique standard de MySQL? Si ce n'est pas le cas, quels sont les RDBMS open source supportant quelque chose de similaire aux procédures stockées Java d'Oracle?
5 Réponses :
PostgreSQL prend en charge les langues de procédure multiples et un projet existe pour étendre PostgreSQL avec PL / Java comme la langue.
Je ne recommande pas de mettre trop de code dans la SGBDM. Les outils pour développer, tester et déboguer du code dans la couche d'application sont meilleurs que les outils pour le code dans la SGBDM.
De plus, de nombreux développeurs ne comprennent pas que le code à l'intérieur des SDBMS devrait obéir à l'isolement des transactions. Ils essaient d'envoyer des emails des déclencheurs et ainsi de suite. Je pense que le code avec les effets secondaires doit être dans la couche d'application, de sorte que vous ne créez pas d'effets fantômes (par exemple, un courrier électronique peut notifier à une modification de la base de données, même si le changement a été renvoyé).
Bien sûr, personne dans leur esprit droit envoie un courrier électronique directement à partir du SGBDM (le serveur de messagerie peut être réduit par exemple). La bonne façon de procéder est d'ajouter l'e-mail à une table de files d'attente de messagerie et d'avoir un processus distinct de vérifier cette table d'attente de messagerie et d'envoyer le courrier électronique. Cela résout le problème de la transaction, car une restauration réduirait l'addition de l'e-mail à la table de file d'attente.
Je suis entièrement d'accord avec la facture, mais je peux imaginer des règles commerciales stockées (non traitées) dans la base de données. Je pense à beools ici. Le moteur serait dans l'application, mais les règles pourraient être dans la base de données avec une gestion de la direction.
Une telle bête serait intéressante pour les scénarios où non seulement les paramètres changent, mais aussi les formules peuvent changer.
Si vous pouvez utiliser HSQLDB, vous pouvez appeler des méthodes Java directement à partir de SQL: http://hsqldb.org/doc/2.0/guide/sqlroutines-chapt.html#n1240c
Il est difficile de donner de bons conseils en fonction des informations limitées que vous avez fournies jusqu'à présent. Toutefois:
... L'exemple implique un type de données basé sur des graphiques (structures chimiques) qui ne peuvent pas être adaptées à une requête en utilisant des fonctions MySQL intégrées. La bibliothèque Java convertirait la requête et le contenu d'un champ de texte en un objet en mémoire pouvant être assorti. Garder cette logique dans la couche de DB serait, par exemple, de conserver des jointures dans la base de données, ce qui semble être là où ils appartiennent. C'est l'idée, au moins.
Je ne pense pas que je voudrais utiliser Java de la base de données dans MySQL pour cela. Au lieu de cela, je pense que je considérerais les options suivantes:
Utilisez un mappage d'objet-relationnel tel que JDO ou JPA (par exemple en utilisant Hibernate) pour traiter le mappage entre votre modèle de données graphique et quelle offre la base de données fournit. Vous n'avez pas nécessairement besoin d'utiliser un SGDBS comme backend, mais c'est probablement le meilleur endroit pour commencer ... Sauf si vous avez déjà trouvé que ceci est un problème de performance.
Regardez un autre regard sur votre modèle de données et vos modèles d'accès aux données. Voyez si vous pouvez déterminer une certaine transformation qui permet de mettre en œuvre les principales requêtes de votre application sous forme de table (efficace), sans recourir à la logique d'application côté serveur.
Si vous avez besoin d'utiliser la logique d'application côté serveur (pour des raisons de performance!) Coller avec les mécanismes pris en charge par votre SGBDM. Par exemple, dans Oracle, vous utiliseriez PL / SQL et PostgreSQL, vous avez plusieurs options. Soyez prêt à passer à différents RDBMS qui conviennent mieux à vos exigences de votre application.
i (personnellement) éviterait en fonction d'une branche expérimentale de certaines bases de données:
considère ce qui se passe si la branche expérimentale n'est pas fusionnée dans la branche principale. Vous seriez coincé avec votre base de code en fonction d'une succursale qui n'est pas prise en charge, et est susceptible d'arrêter d'être maintenue et de pétiller.
Utilisation d'une succursale RDBMS (actuellement) non supportée sera un obstacle aux autres personnes susceptibles d'utiliser votre logiciel.
Maintenant évidemment, si la viabilité à long terme de votre logiciel n'est pas une préoccupation principale, vous pouvez choisir d'ignorer ce conseil. Mais cela compte probablement pour quelqu'un; par exemple. Votre superviseur de recherche.
L'utilisation d'un orm ne résout rien. Il masque simplement le problème: blogs.dédéward. COM / 2006/06/26 / ...
Je me rends compte que c'est un ancien article, mais il porte une mise à jour. La possibilité d'appeler Java à partir d'un déclencheur de base de données est fait partie des "routines et types SQL pour le langage de programmation Java" (SQL / JRT).
En savoir plus À ce sujet sur Wikipedia à https://fr.wikipedia.org/wiki/ SQL / JRT .
Parmi les moteurs de base de données conformes sont ..
Hypersql: http://hsqldb.org/ Oracle: https://www.oracle.com/database/
+1 intéressant. J'ai toujours simplement enregistré des données dans une base de données et implémenté une logique dans une couche d'entreprise. En fait, j'ai été religieux à ce sujet. Je serais intéressé à voir un projet où appeler le code Java d'une DB était une bonne décision de conception. Des liens?
Fonctions personnalisées qui dépassent les capacités de DB par exemple. Cependant, je suis également très question de la valeur de pouvoir faire une telle chose. Les DB sont là pour stocker / gérer des données, pour ne pas faire des affaires professionnelles.
@Darren, l'exemple implique un type de données graphique (structures chimiques) qui ne peut pas être adaptée à une requête à l'aide de fonctions MySQL intégrées. La bibliothèque Java convertirait la requête et le contenu d'un champ de texte en un objet en mémoire pouvant être assorti. Garder cette logique dans la couche de DB serait, par exemple, de conserver des jointures dans la base de données, ce qui semble être là où ils appartiennent. C'est l'idée, au moins.