Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Apache Derby or MySQL

 
J boradic
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm very new to SQL database development and have narrowed my choices down to apache derby and mysql. I'm looking for the easiest to use solution while implementing hibernate to deal with the majority of my persistence problems. Any suggestions would be great, perhaps its just apples to oranges but I'd rather find out the major differences before choosing a solution.
 
Ulf Dittmer
Rancher
Posts: 42969
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Definitely apples and oranges. Those two DBs have very different characteristics. While Derby has a standalone server mode, it's most often used as en embedded DB in the same JVM as the client code (in other words, not as a DB server, but as a client-side DB). Is that what you intend to do? If you're looking for a DB server, I'd compare MySQL to PostgreSQL instead.
 
J boradic
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Server side POJO persistence with hibernate... ya I researched apache derby a little more to realize it wasn't at all what I'm looking for. I'm currently working with JDBC MySQL and Hibernate to provide persistence in my app. I'm pretty new to this just learning the bare essentials then going from there. Lots of decisions to make without a lot of experience. Another quick question, when should I opt for direct storage in the database and when should I opt to use hibernate? Also, how is concurrent modification handled in MySQL(if I make beans I can synchronize obviously).
 
Ulf Dittmer
Rancher
Posts: 42969
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
DB transactions take care of concurrent modifications (meaning that you'll get an exception during a transaction commit if it's about to clobber a value that was concurrently changed while the transaction was ongoing).

While using raw JDBC is sometimes preferable, I generally find it convenient to have objects that map to relational tables - from there to using those objects with JPA (or Hibernate, or some other ORM system) is a small step. If I were to build a new system I'd go with ORM.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic