We are making an application which is machine dependent.
Now we deploy our application on several client machines but problem is that every client have database from different vendors. Currently we are facing conflicts between SQL Server and Oracle.
Our Application built on Oracle database and now we want to access SQL Server. Is there any way to do it as I am little amateur with databases and I dont want to change the queries and configuration settings for different databases.
What you need is something that provides a layer that provides database independence. There are a variety of ways of doing this.
You could use a ORM (Object Relational Mapping) technology such as JPA (with Hibernate being the prime example). A typical JPA implementation has backends for a range of different databases.
You could use an existing product that supports database independence by (roughly speaking) mapping SQL statements between different SQL dialects.
Some people suggest using ODBC.
You could implement a DAO API with different DAO implementation classes for each backend database. If you stick to SQL-92 conformant DDL and DML as much as possible, there is a good chance that there will be a lot of commonality between the DAO implementations. (JDBC provides database independence at the API level, provided you don't use vendor specific extensions. I recall having problems with Oracle's JDBC drivers doing things in non-standard ways ... but they may have gotten their act together now.)
... I dont want to change the queries and configuration settings for different databases.
If you use an ORM and its query language, you won't have to. If you implement your database stuff using SQL and JDBC, it is largely a matter of sticking to the SQL standard and the standard JDBC API methods respectively.
Related question:
DB Independent Java Programming - Suggestions?
Recommended approach is to use ORM tools like Hibernate. if that is not possible then use StoredProcedures ( make sure that it uses only normal PL SQL and no database specific features) for database operations
Create Linked Server and use openquery if necessary.
http://technet.microsoft.com/en-us/library/ms188279.aspx
Related
Let's say there is a web server build on Spark Java with a Postgres backend. There is a Database Connection Pool that allows different Services or Controllers to use a connection and query the database. My question is, where is the SQL stored?
Are they inline:
String sql = "Select * From Users;"
Are queries built in a factory that spits back a string:
String sql = SqlFactory.createQuery(SQL_ENUM.TYPE, params);
Are all queries stored within the Database Server and called as a stored procedure?
Any insight is greatly appreciated.
That's up to the system designers. There's no one right answer, and there are places you didn't mention like configuration files (XML, etc.). Usually there is a mix of multiple sources.
It's a good idea to use PreparedStatement when writing JDBC queries, for security and type safety. But besides JDBC, there is JPA, among other libraries that use SQL under the hood.
As a rule of thumb, stored procedures in the DBMS hold SQL related to maintenance of the DB structures as such. Domain logic for persistence tends to reside in application and middleware code.
Some systems establish data operations declaratively, using annotations.
So the answer, as is common in engineering, is, "It depends."
I am a beginner to jpa and hibernate, I understood that how jpa achieves database independence and persistence provider independence.
I came across the sentence which states
jpa can achieve schema independence
how does jpa achieves this?
JPA is an API, this API is completely abstracted from your data representation and DDL. Also, it is abstracted from the API implementation (unlike going directly for Hibernate).
This means that you can:
Use differing JPA implementations such as Hibernate or Toplink
Use different DB dialects such as Oracle, T-SQL, PostgreSQL
Implement your own JPA implementation
These can be done through annotations AND/OR configuration. So in theory you can switch from Oracle to PostgreSQL without having to recompile your application.
This also means you can do other funky things like:
Use a free, Open Source DB for development, and then Oracle/SQL Server for Production
Use Hypersonic for automated tests, so everything is in memory and torn down automatically.
Use other data-sources such as XML transparently.
You get other niceties like SQL injection protection out of the box, very quick startup time (rather than having to code everything twice), automatic DDL generation when you've defined your entities etc. which get small projects started quicker than the traditional route.
IN REALITY:
Nobody chooses to go from Hibernate to Toplink
Very few people ever implement JPA for a project
Very few people rapidly switch DB backends as each Database performs very differently
Also, the differing dialects can drive out weird bugs.
The configuration aspects and the ability to use things like Hypersonic are useful though.
The other "flip side" to the lovely API abstraction is that the implementation can be too constraining, resulting in very inefficient SQL being produced. This ends up with the developer having to add in native SQL anyway.
Schema independence can be achieved in the same way as DB and provider independence - it is possible to change the schema of all tables simply in configuration. You can change default schema in an orm.xml file included in persistence.xml via persistence-unit-defaults.
You may also specify schema via #Table annotations.
In my current project, I am trying to unify query language for accessing heterogeneous database. Heterogeneous database means their query language for accessing data is different. For instance, SQL is a query language for accessing data from Apache Derby, while nonSQL for MongoDB.
My question is "Is there any domain specific language, which have been proposed to unify heterogeneous databases ? "
Please feel free to direct me other efforts as well.
That's quite an interesting question. There is at least one proposed solution called UnQL (Unstructured Data Query Language) - http://www.couchbase.com/press-releases/unql-query-language.
I suppose out of the box UnQL will work at least for CouchDB and SQLite. This just seems to be a great step ahead.
Personally I would say such a task seems to be a tricky one because of the conceptual differences between structured and unstructured data approaches. Anyway, it should be relatively easy to develop such a DSL for a well defined SQL and NoSQL data models used by a certain application.
There is a project called Hibernate OGM, which aims to generalize JPQL to NoSQL databases.
From their web page:
Hibernate Object/Grid Mapper (OGM) aims at providing Java Persistence (JPA) support for NoSQL solutions. It reuses Hibernate Core's engine but persists entities into a NoSQL data store instead of a relational database. It reuses the Java Persistence Query Language (JP-QL) to search their data.
I don't tried it out for myself, so I cannot say how usefull it is.
JSONiq can process data from different SQL and NoSQL products.
The open source implementation of JSONiq has connectors for Couchbase, Oracle NoSQL, SQLite, and JDBC.
For instance, the following slidedeck showcase the same query being executed on both Couchbase and MongoDB: https://speakerdeck.com/wcandillon/jsoniq-the-sql-of-nosql
SPARQL is a W3C-standardized query language that works on top of an abstract data model (RDF), rather than a specific type of database, which makes it very suitable as an enabler for heterogeneous database querying.
Implementations of SPARQL exist on top of various NoSQL databases, including native RDF databases (often referred to as triplestores), as well as on top of relational databases.
I am learning Java EE and I downloaded the eclipse with glassfish for the same. I saw some examples and also read the Oracle docs to know all about Java EE 5. Connecting to a database was very simple. I opened a dynamic web project, created a session EJB , I used EntityManager and with the get methods could access the stored data table.
For my next project I had create a simple class and then access some DB table. The very first problem I encountered was that the PersistenceUnit attribute would only be recognized by EJB,Servlet etc and not a simple java class. So then I could not use the EntityManager way(or can I?)
I was asked to go via the "JDBC" way. The very first problem I encountered was to get the connection to the DB. It seems all this must be hardcoded. I had a persistence.xml with which I could easily configure the data base connection. Even setting up a driver for the DB was easy. Also there no get/set methods in the JDBC for accessing table entities.
How do I understand JPA and persistence in relation to JDBC? What was JPA thought for? Why is there set/get methods? Can someone throw some light on the essence of these two and what are the pros/cons without "jargons"?? Please also suggest some links. A simple google search for JPA and JDBC differences led me to some sites full of "terminology" I couldn't follow :(
In layman's terms:
JDBC is a standard for Database Access
JPA is a standard for ORM
JDBC is a standard for connecting to a DB directly and running SQL against it - e.g SELECT * FROM USERS, etc. Data sets can be returned which you can handle in your app, and you can do all the usual things like INSERT, DELETE, run stored procedures, etc. It is one of the underlying technologies behind most Java database access (including JPA providers).
One of the issues with traditional JDBC apps is that you can often have some crappy code where lots of mapping between data sets and objects occur, logic is mixed in with SQL, etc.
JPA is a standard for Object Relational Mapping. This is a technology which allows you to map between objects in code and database tables. This can "hide" the SQL from the developer so that all they deal with are Java classes, and the provider allows you to save them and load them magically. Mostly, XML mapping files or annotations on getters and setters can be used to tell the JPA provider which fields on your object map to which fields in the DB. The most famous JPA provider is Hibernate, so it's a good place to start for concrete examples.
Other examples include OpenJPA, toplink, etc.
Under the hood, Hibernate and most other providers for JPA write SQL and use JDBC to read and write from and to the DB.
Main difference between JPA and JDBC is level of abstraction.
JDBC is a low level standard for interaction with databases. JPA is higher level standard for the same purpose. JPA allows you to use an object model in your application which can make your life much easier. JDBC allows you to do more things with the Database directly, but it requires more attention. Some tasks can not be solved efficiently using JPA, but may be solved more efficiently with JDBC.
JDBC is a much lower-level (and older) specification than JPA. In it's bare essentials, JDBC is an API for interacting with a database using pure SQL - sending queries and retrieving results. It has no notion of objects or hierarchies. When using JDBC, it's up to you to translate a result set (essentially a row/column matrix of values from one or more database tables, returned by your SQL query) into Java objects.
Now, to understand and use JDBC it's essential that you have some understanding and working knowledge of SQL. With that also comes a required insight into what a relational database is, how you work with it and concepts such as tables, columns, keys and relationships. Unless you have at least a basic understanding of databases, SQL and data modelling you will not be able to make much use of JDBC since it's really only a thin abstraction on top of these things.
JDBC is the predecessor of JPA.
JDBC is a bridge between the Java world and the databases world. In JDBC you need to expose all dirty details needed for CRUD operations, such as table names, column names, while in JPA (which is using JDBC underneath), you also specify those details of database metadata, but with the use of Java annotations.
So JPA creates update queries for you and manages the entities that you looked up or created/updated (it does more as well).
If you want to do JPA without a Java EE container, then Spring and its libraries may be used with the very same Java annotations.
The difference between JPA and JDBC is often the deciding factor, as the two database technologies take very different approaches to work with persistent data. JDBC, allows developers to construct database-driven Java programs utilizing object-oriented semantics
JPA is database-agnostic, meaning that the same code can be used in a variety of databases with few modifications. JPA serves as a layer of abstraction that hides the low-level JDBC calls from the developer, making database coding considerably easier
hibernate is implementation of JPA
hibernate you can see further details from here about jpa Query
JDBC is a layer of abstraction on top of vendor-specific relational DB drivers. Without JDBC you would have to deal with peculiarities of a specific DB (not much fun). JDBC, however, is too low-level and entails a lot of boilerplate code.
JPA is a specification of an ORM (just an interface). It's useless without an implementation.
ORM is a kind of framework concerned with saving and retrieving objects to/from the relational DB. There are many ORMs out there with different levels of abstraction. Some of them require manually-written SQL.
Some of ORMs implement JPA (Hibernate or EclipseLink, for example). Most of them are built on top of JDBC.
Such ORMs provide the maximum level of abstraction to the point you almost never have to write SQL queries. Some people love JPA-based ORMs (they reduce boilerplate), some hate (abstraction is leaky, specification is overly complex and there are lots of corner cases).
Java analogy:
class ORM extends JDBC implements JPA {
}
Persistence layers have protocols versions so abstractions also have versions therefore you need ranges of supported versions. It is version hell
I want to make java code that creates a sample database in 3-4 DBMS like mysql, oracle sql, sql server etc installed on any OS - windows, linux distro, Mac OS etc.
How can I make my code:
automatically (or with help from a user) locate the jdbc driver in the computer.
execute a fixed set of sql commands which will work regardless of the DBMS used.
Please suggest how I can do all these things.
EDIT:
This will be a back end kind of app.
I am a little new to JDBC, so I am looking for simple/elementary solutions to begin with.
Will switch to advanced ones later.
Thanks.
Bundle drivers for all the supported databases with your program. Users shouldn't have to deal with JDBC drivers or connection strings. (Provide a UI to edit the latter, which might differ between the databases.)
Use an ORM (like Hibernate); or, if you don't need to populate the database with data, a database migration library (like Flyway)
1, See here... How to use a JDBC driver from an arbitrary location
2, Different DBMSs use similar but not identical syntax. You have at least 3 options:
only use sql commands that are supported by all the DBMSs you're interested in;
sniff the DBMS and modify your SQL statements accordingly;
use a framework that comes with an SQL abstraction layer (e.g. Java Persistence API's JPQL). I suspect this may be too much work for what you're after.
If you want to let users find the JDBC drivers, then you shall deal with ClassLoaders and implementing custom ClassLoaders, which is not a simple thing to do. Or you shall use a Application Server which will handle this for your.
Otherwise you shall have all your JDBC drivers available in your class-path.
By the way JDBC is an adapter for working with most RDBMSes which work with SQL, each database provider made vendor specific customization to their SQL. For example you have sequences in Oracle and auto-numbers in MySQL. Or you can use limit in MySQL queries which is not available in Oracle. The solution to this problem is doing what Hibernate does (having Dialects for handling database vendor specific stuff.)