I'm wondering why is ORM so popular and everybody is using ORM implementations of JDO and JDA specifications, instead of using object databases that implements these specifications as well. The performance is much better using Object database.
objectdb (JDO, JPA)
db4o (JDO)
Am I right if I say that it is because developers need to use both object model and relational model in their applications ?
What about ORDBMs ? Is there any ORDBM (which worths a try) around or can Object Relational Mapping together with relational database be considered ORDBM ?
The main reason why people use an RDBMS with an OR Mapper rather than an object database is that RDBMS are deeply entrenched, well understood and well supported by everyone. If you use an object database you'll have problems
finding people to support it
using your existing tools for reporting, backups, etc.
having other applications access the data
There's probably also still a lot of doubts (whether justified or not I can't say) whether object databases can really deliver the same or better performance and safety in a real word scenario.
In my experience, using an object database resulted in much less code, and a much cleaner project.
It made the difference between a 6-week learning curve for an RDBMS + ORM (LINQ-to-Entities) and a 1-week learning curve for object databases (for db4o).
The commonly used DBMSs you may be familiar with (e.g. Oracle, SQL Server, DB2, MySQL, PostGreSQL) are not relational. They are based on the SQL model, which is something quite different even though it resembles the relational model in some ways.
An Object-Relational DBMS means the same thing as a Relational DBMS. It's another way of saying that a RDBMS in principle will support any unlimited set of data types and relational operations upon them. O/R Mapping software really only addresses the fact that SQL DBMSs don't do that very well.
Related
Today I've found some interesting library - ActiveJDBC. It provides RoR-like ActiveRecord interface, and I'm thinking on Hibernate replacement, but there is a question - can ActiveJDBC handle really big queries and results and is it clever to use it instead of Hibernate in any application?
I'm a developer of ActiveJDBC, so take my advice with a grain of salt :). I have not performed extensive performance comparison tests, but simple tests (storing and reading tens of thousands of records) revealed that ActiveJDBC is about twice as slow as JDBC, and Hibernate is about twice as slow as ActiveJDBC, which makes Hibernate about 4 times slower than plain JDBC. Overall, ActiveJDBC is a lot thinner than Hibernate, that was the idea for developing it. Please see this blog: Just how thin can a framework be? ActiveJDBC vs Hibernate.
Hibernate is architecturally built with client/server model in mind in the 90s (sessions, lazy loading, object graphs. etc.), while ActiveJDBC was built in 2009 primarily for request/response of modern web applications and uses a pass-through model. Depending on your logic, data and database optimizations, your mileage will vary, but I'm confident that ActiveJDBC will almost certainly be faster.
Mubin pointed out the fact that you will need migrations. I'd say this is partly correct. Migrations system is always a good idea, but ActiveJDBC does not care how tables were created, as long as they exist.
cheers
I am looking for best solution for caching large amount of simple transactional pojo structure in memory. Transactions happen at oracle database on 3-4 tables by external application. Another application is kind of Business Intelligence type, which based on transactions in database evaluates updated pojos(mapped to table) and applies various business rules.
Hibernate solution relies on transactions on same server; where as in our case transactions happen some where else, and not sure cached objects can be queried.
Question:
Is there oracle jdbc API that would trigger update event on java side?
Which Caching solution would support #1,
Is cached objects can be queried?
Oracle databases support Java triggers, so in theory you could implement something like this yourself, see this guide. In theory, your Java trigger could invoke the client library of whichever distributed caching solution you are using, to update or evict stale entries.
Oracle also have a caching solution of their own, known as Coherence. It might have integration like this built in, or at least it might be worth checking it out. Search for "java distributed cache" for some alternatives.
As far as I know Hibernate does not support queries on objects stored in its cache.
However if you cache an entire collection of objects separately, then there are some libraries which will allow you to perform SQL-like queries on those collections:
LambdaJ - supports advanced queries, not as fast
CQEngine - supports typical queries, extremely fast
BTW I am the author of CQEngine. I like both of those libraries. But please excuse my slight bias for my own one :)
I am a java/j2ee developer. I always like JPA/JTA or hibernate for ORM. Since it gives me portability. But for large scale application, portability is not that important sometimes. Lots of time they ask to use PL/SQL as BE. I always find it un necessary. Apart from ARRAY and scheduling etc. Cos, with PL/SQL, application logic gets fragmented in java and PLSQL.
What are business / application scenario where PLSQL is better in-terms of performance / design / maintainability.
The answer to this usually depends on whether you prefer objects or relational databases.
A DBA would argue that middle tier applications come and go, but relational databases live forever. Portability is rarely important for relational databases, especially if a firm has made a large investment in Oracle. A decision to migrate to another vendor won't be made lightly.
A DBA may prefer stored procedures because it acts like a Java interface and shields users from the underlying schema details. S/he can modify the schema as will as long as the stored proc parameters don't change.
Sometimes stored procedures make sense for performance reasons. Why query for a large data set on the middle tier, process it, and put it back in the database when you can do all the calculations on the database server?
Using stored procs does force you to do maintenance on both middle tier and server, but that's a choice.
I don't believe there's a hard and fast answer that would say objects or stored procedures are always right. If that's what you're looking for, I'm afraid you're going to be disappointed.
Put it simply PL/SQL is the closer you can get to your Oracle DB therefore performance comes first in mind in situations where you are dealing with loads of database entries.
I am using Spring MVC for an application that involved a multilevel back end for management and a customer/member front end. The project was initially started with no framework and simple native JDBC calls for database access.
As the project has grown significantly(as they always do) I have made more significant database calls, sometimes querying large selection sizes.
I am doing what I can to treat my db calls to closely emulate Object Relational Mapping best practices, but am still just using JDBC. I have been contemplating on whether or not I should make the transition to hibernate, but was unsure if it would be worth it. I would be willing to do it, if it was worth a performance gain.
Is there any performance gain from using Hibernate( or even just Object Relational Mapping) over native SQL using JDBC?
Is there any performance gain from using Hibernate (or even just Object Relational Mapping) over native SQL using JDBC?
Using an ORM, a datamapper, etc won't make the same SQL queries run faster. However, when using Hibernate you can benefit from things like lazy loading, second level caching, query caching and these features might help to improve the performances. I'm not saying Hibernate is perfect for every use case (for the special cases Hibernate can't handle well, you can always fall back to native SQL) but it does a very decent job and definitely improves development time (even after adding time spent on optimization).
But the best way to convince yourself would be to measure things and in your case, I would probably create an Hibernate prototype covering some representative scenarios and bench it.
ORM lets you stay inside OOP world, but this comes at the cost of performance, especially with many to many relations in our case. We were using Hibernate as default, doing performance optimization with jdbc where required.
Hibernate will make the development and maintenance of your app easier, but it won't necessarily make DB access quicker.
If your native JDBC calls use inefficient SQL then you might see some performance improvement as HIbernate tends to generate good SQL.
I've got a java server (not web based, more like a big, many-threaded standalone application) that needs to talk to a MS SQL Server database.
I just worked on a different project that ported a home-grown O/R layer from oracle to SQL Server, and it ran into significant problems because of too many oracle assumptions (locking, mostly). So What O/R layer should I use?
Edit: I have heard of Hibernate, but everything else is useful!
Specifically though, do any of these APIs/frameworks help with the peculiar shortcomings of SQL Servers locking strategy in a multi-threaded environment?
Hibernate is the usual choice. Besides that you can take a look at Oracle TopLink, iBatis, whatever suites you best.
I've used Hibernate and iBATIS. Choosing one over the other depends upon the situation.
Hibernate:
is much pickier about database schema
generates most of the sql for you
more features
more complex
iBATIS:
works better when you want to work with existing schema
requires you to write your own sql
easier to learn
They both work well with SQL Server and handle multi threading.
I suggest Cayenne.It supports a lots of databases. It is open source,too. But there is no so much documents. You can use cayenne with struts.
I have also used BEA Kodo with Microsoft SQL Server (back when it was Solarmetric Kodo). At the time, it was far more feature rich than Hibernate and any JDO implementation. That's no longer the case, though it still has a number of unique performance/scalability features.
Hibernate is the most popular one available today. My personal favorite is TopLink.
The key standards you want to look for are EJB3, Java Persistance API (JPA), and Java Data Objects (JDO). JPA is probably the most important of the bunch as its easier to use and is meant as a common API for using Hibernate, JDO, Toplink, EJB3, etc.
Hibernate is good. But there are different flavors of Hibernate implementation. I suggest Hibernate 3.x (3.2?) with JPA. I also usually use Spring 2.5 as the framework for the business logic. Hibernate and Spring work especially well together, because they can share name resolving scopes to a degree, which lesses the confusion on how to accesses O/R objects.