I found an article from 2008 discussing how to call Java code from MySQL. There were a lot of caveats and disclaimers because the process involved working with an experimental branch of MySQL.
For a project I have in mind, it would be very useful to be be able to access Java libraries within MySQL, analogous to Oracle's Java Stored Procedures. Does this capability now exist as a standard feature of MySQL? If not, what open source RDBMSs support something similar to Oracle's Java Stored Procedures?
PostgreSQL supports pluggable procedure languages, and a project exists to extend PostgreSQL with PL/Java as the language.
I don't recommend putting too much code in the RDBMS. Tools to develop, test, and debug code in the application layer are better than tools for code in the RDBMS.
Also many developers don't understand that code inside the RDBMS should obey transaction isolation. They try to send emails from triggers and so forth. I think code with side effects should be in the application layer, so you don't create phantom effects (e.g. an email may notify of a database change, even though the change was rolled back).
If you can use HSQLDB then you can call java methods directly from SQL: http://hsqldb.org/doc/2.0/guide/sqlroutines-chapt.html#N1240C
I fully agree with Bill, but I can imagine business rules being stored (not processed) in the database. I'm thinking of drools here. The engine would be in the application, but the rules could be in the database with a management front-end.
Such a beast would be interesting for scenarios where not only the parameters change, but also the formulas can change.
It is difficult to give good advice based on the limited information that you have provided so far. However:
... the example involves a graph-based data type (chemical structures) that can't be matched to a query using built-in MySQL functions. The Java library would convert the query and contents of a text field into an in-memory object that can by matched. Keeping this logic in the DB layer would, for example, keep joins within the database, which seems like where they belong. That's the idea, at least.
I don't think I would use database-side Java in MySQL for this. Instead, I think I would consider the following options:
Use an object-relational mapping such as JDO or JPA (for example using Hibernate) to deal with the mapping between your graph-based data model and what the database provides. You don't necessarily have to use an RDBMS as the backend, but that is probably the best place to start ... unless you've already found that this is a performance issue.
Take another look at your data model and data access patterns. See if you can figure out some transformation that allows your application's main queries to be implemented as (efficient) table joins without resorting to server-side application logic.
If you do need to use server-side application logic (for performance reasons!) stick with the mechanisms supported by your RDBMS. For example, in Oracle you'd use PL/SQL and PostgreSQL you have a number of options. Be prepared to switch to a different RDBMS that better suits your application requirements.
I (personally) would avoid depending on an experimental branch of some database:
Consider what happens if the experimental branch is not merged back into the main branch. You would be stuck with your code base depending on a branch that is not supported, and is likely to stop being maintained and fizzle out.
Using a (currently) unsupported RDBMS branch will be an impediment to other folks who might want to use your software.
Now obviously, if the long term viability of your software is not a primary concern, you could choose to ignore this advice. But it probably matters to someone; e.g. your research supervisor.
I realise that this is quite an old article, but it bears updating. The ability to call java from a database trigger is is part of the "SQL Routines and Types for the Java Programming Language" (SQL/JRT) standard.
Read more about this on Wikipedia at https://en.wikipedia.org/wiki/SQL/JRT.
Amongst the compliant database engines are..
HyperSQL: http://hsqldb.org/
Oracle: https://www.oracle.com/database/
Related
Currently I am migrating databases from Oracle to MySQL. I mainly use Java to send queries to the database using JDBC. In the process of migrating, I need to change a lot of my queries in the Java code (the queries are hard-coded) as they will not work in MySQL.
I want to be able to recode my queries in such a way that I can easily switch between the databases if problems arise; I am changing all my queries to standard SQL but there are areas where this is not possible. I am thinking of having two versions of the queries, one for Oracle and one for MySQL so I can switch between both (I will have two versions temporarily just to see if MySQL can cope with our needs). However this seems like a terrible idea - does any one have any advice on a better way they would do this?
You have a bunch of options.
Firstly, many people now use Object-Relational Mapping (ORM) tools to connect applications to SQL databases. These come in a variety of different flavours - Hibernate is popular - and allow you switch between databases at very little cost. However, they do have a fairly steep learning curve. Inexperienced developers often struggle with performance problems in ORM applications.
If you stick with "traditional" JDBC, I suggest you take the body of the SQL out of the Java code, and treat it like a resource. As Henry suggests, you could use property files, and use parameter placeholders (ideally named placeholders, using the Spring template). While this does spread the code for a given piece of functionality into two files, it makes it easy to quickly refine the SQL and test new versions.
One possibility is to store the queries in a properties file. You would have one for Oracle and one for MySql.
I must add - ORM is good advice and will work... when you are starting with a fresh application and you can design your application to work on a domain model.
In this case however there is an existing application that invokes a great number of SQL queries. ORM based queries (HQL, JPQL) translate to SQL just fine; SQL does not by definition translate to the ORM layer however, major changes will be needed to make it a more object oriented approach to the data.
The problem will still persist even when you do manage to work in an ORM layer. There is already a major difference between MySQL and Oracle in how primary key generation works for example; MySQL uses auto-numbering where Oracle uses a sequence. Likely you already have an existing datamodel that you need to reverse engineer into the ORM layer code; it isn't going to be cross-database code.
Greetings everybody,
I came across the feature of using java in oracle, a few days back. Ever since I am wondering about the
possibility of writing static methods in java replacing regular PL/SQL logic.
As I have reasonably adequate experience with
java plus the rich libraries it offers, I am tempted to write java methods instead of regular PL/SQL. Would this be
a good practice?. Will there be much performance overhead in doing so?. Thanks in advance.
There will be overheads involved in your decision to walk away from PL/SQL into Java code.
Although i am not a big believer of putting business logic into PL/SQL, i have seen just too many companies doing that, including my own.
The "performance consideration" of doing this does not come as whether or not to use static methods. For example, you may need to declare an arraylist to sort the values, and depending on the values, retrieve more results from the database in another query.
IMO, i would put business logic in my application, and not invest in PL/SQL. This also helps to ensure DBMS portability and not buy-in.
It depends!
They are two languages for different purposes!
What kind of operations do you want to do?
Every operations that touches data layer(I know it's debatable)
Massive Sql operations with large data processing( bulk operations)
To manage any kind of transaction
The job can be easily done in Pl/Sql
Are you writing code that is strictly tied to Sql data types?
Monitoring the relations between the code and dependent db objects
In this case, I believe Pl/SQL is the best choice for performance.
Attention, I wrote PL/SQL:
PL as procedure language(2nd choice)
SQL as data query language(1st choice)
The power of this two languages, strictly tied in Oracle, let you write application which access data in Oracle in faster and easier way than in any other language.
Do you need:
Operating system operations
Directory and file operations
Massive mails operations
Network operations
Other things you can't do in:
SQL (1st choice)
PL (2nd choice)
write code to reuse in architecture like Enterprise Java Beans
Write code to reuse elsewhere
In this case I think Java is a better choice, 3rd choice in Oracle.
But I'm not reinventing the wheel, this information are largely accessible and proved by Oracle experts like Tom Kyte etc.
Just some useful link to search:
PL/SQL advantages over java
Oracle Docs
Tom Kyte site
OTN forum
I think it can be acceptable if you store the CRUD operations as stored procs. If you use any ORM framework, then you might map the SPs. It is more usual that the database is the more stable part of the application. The application might be refactored or replaced, but the database does not change (it is just my experience).
I've experience with Toplink to translate objects to database and vica versa. But this was all part of a JSP site and now I did some EJB stuff with it to. Now is my question: is it good to work with stuff like Toplink in a Java Desktop application or is it more common to use native sql stuff from Java?
Maybe some experience of prof. developpers might be good. I need to develop a seriously application for a client. I'm doing it in Java and I'm gonna store the data in a database.
Thanks
ORM is nice if your data model is well structured, not overly complex and, most of all, if you have control over it.
Legacy databases or poorly modelled ones are harder to be represented with ORM, and doing so would be strongly discouraged, as your application would add further complexities over those implied by the model itself.
If you are comfortable with some ORM tool such as Hibernate and your database is fairly well done, go for it. They sure save you a lot of boilerplate code and have some nice query optimization code under the hood. Otherwise, you may want to use JDBC directly or some other framework to simplify JDBC use but still using plain SQL. For such situations I recommend MyBatis.
TopLink (and EclipseLink/JPA) work just as well in a desktop application as in a server side application. In fact TopLink has been around since the 90s with client-server Smalltalk apps before the server side was popular.
It's dependent on your use cases
ORM technologies can nicely abstract away database specifics and allow you to concentrate of the domain model. However, there are circumstances where using an ORM layer is not appropriate (extremely large data sets can cause performance issues for example, database schemas that are difficult to map to objects is another).
I would recommend using a JPA compliant technology such as Hibernate. That way you're using the ORM that implements a Java standard and you can more or less swap in and out implementations.
For everything else then JDBC is a flexible friend
depends on database volume too. For databases with huge data try using hibernate. It might be of great help rather than writing JDBC code
may i know in 'nosql' there is limitation just like bigtable where we should 'denormalized' our table/entity ?
any api wrapper that allow we to write code once and can be used for google app engine bigtable and nosql ? (something like hiberanate)
Yes, for example in MongoDB you don't have joins since it is non-relational, so it does change how we store and browse the data.
As MongoDB is non-relational (no
joins), references ("foreign keys")
between documents are generally
resolved client-side by additional
queries to the server. Two conventions
are common for references in MongoDB:
first simple manual references, and
second, the DBRef standard, which many
drivers support explicitly.
It seems that the consensus is to denormalize and duplicate to accelerate the reads to avoid the cost of joining distributed data all toghether, with the join and merge logic done on the application level.
As to whether it is an absolute requirement to denormalize the database, I am not sure (other SO members can probably enlighten us). But I think the database should be modeled with these "limitations" in the mind along with a good study of how the data is going to be queried. This should give the least impedance to the process.
See Also:
Bigtable database design theory
GAE - How to live with no joins?
Any API wrapper that allow we to write
code once and can be used for google
app engine BigTable and nosql ?
(something like Hibernate)
JDO is datastore-agnostic, so it might just provide what you want to some extent.
Seems there are lots of recent projects to use JDO and JPA with "NoSQL" products.
See:
Datanucleus-Cassandra
Datanucleus-Cassandra-Plugin
Any API wrapper that allow we to write code once and can be used for google app engine BigTable and nosql ? (something like Hibernate)
While abstraction libraries definitely help portability, you have to take into consideration the particular platform you're running on. If you're going to go with Google App Engine, you have to be aware of the incurred startup costs inherent with additional abstraction libraries.
You should weigh the pros and cons of using something like JDO or JPA. Also take a look at the Objectify library that offers a more native interface that has the downside of being coupled to the App Engine Datastore.
Can anyone explain why was idea to store Java class in Db? What it is good for? And how to create stored procedure with Java class?
Best regards!
Oracle introduced stored procedures into their database in release 8i. The i stood for "internet", as in "internet-ready", which basically was a bit of marketing. But Java Stored Procedures allowed Oracle to extend the range of functionality available in the database queite dramatically, by leveraging the vast amount of Java libraries available. A lot of the new database functionality in Oracle 8i was PL/SQL wrappers of Java libraries, notably the XML stuff.
Significantly Oracle re-wrote a lot of that functionality into native C in Oracle 9, because it ran a lot faster than the wrapped Java stuff. I know, fancy that.
For us, when does it make sense to use Java Stored Procedures? Basically, when there features available in Java which are not available in the native database language. For instance, I have written JSPs to wrapper the ICE Syslog java classes, so my PL/SQL logging routines can write to syslog files. This indicates a very common use case for Java - extending the reach of our database applications into the OS. Perhaps the most common use of a JSP is to write a host command which allows a PL/SQL program to fire an external executable.
I know some developers who write JSPs because they know Java and don't want to learn PL/SQL. This is not good enough for two reason:
It is always better to work with built-ins rather than re-inventing the wheel
As I mentioned already, Java in the database doesn't perform as well as native code.
Of course, if you are wroking on a product which has to run against several different database products, then Java's cross-platform adaptability is very appealing. The different flavours of DBMS are most divergent when it comes to their procedural languages (T-SQL vs PL/SQL, etc) because there is no standard for it, unlike SQL.
If you want to learn about writing JSPs in Oracle, the online documentation is a good place to start. If it turns out you are using a different database rather than Oracle, well I'm sure that product has its own equally fine manual.
Not really sure what the question is... the idea was just to do stored-procedure-like oeprations in Java instead of more arcane and unfamiliar stored procedure scripting languages. Here's how it works: http://www.oracle.com/technology/tech/java/jsp/index.html
Probably for the benefits listed here.
An example of how to create them you may find here Oracle and Java Stored Procedures.
I think the question is about the Object Relational Mapping. You can declaratively describe the rules of how to map Java objects to the relational database tables. If you do, you can save a lot of development time writing JDBC code, tracking object changes, implementing loading strategies etc.
http://en.wikipedia.org/wiki/Object-relational_mapping
Sybase ASE is also capable of Java stored procedures, however only Java 1.2 in ASE 15, IIRC.
For the benefits - see other anwers.
Debuger,
As some of the other posters have also asked, your question is very vague.
Are you referring to:
Java based stored procedures in a database?
Mapping a Java Object into a database table?
Storing the byte code of a Java class in a database table?
For point 1, some databases offer a programming hook to allow you to code your stored procedures & functions using Java and exposing them to the SQL engine
For point 2, there are Object-Relational frameworks which will map a Java object (instance) into relational tables for read-write access. (Example: see Hibernate)
For point 3, You could hypothetically write a ClassLoader that will load classes from a database record containing a BLOB of the class in question.
Hope that helps some.