Hello,
I'm using PostgreSQL (and I'm very happy with that), however I'm looking for Java-based DBMS and Derby is a proper solution. I'm just curious how Derby looks comparing to PostgreSQL - performance, features, license etc. Does anyone have made such a comparisons ? Thanks in advance. ML |
Hi Marek,
I have quite a lot of experience with PostgreSQL and am now working for a company that is building a product that will include an embedded Derby database. Good - For a pure java embedded database I am most impressed with derby - it is fantastic to be able to distribute a pure java solution (tomcat etc.) - less moving parts, less dependencies, cross platform - good. We used HSQL to begin with and Derby blows it away for performance. Good - The list here is really helpful and friendly - I can only see good things in the future. (Same should be said for postgres, I would add). I do have some grumbles: Bad - I find the docs confusing esp. with the amount of overlap b/w "cloudscape" and "derby". A lot of useful links/google searches dead end into IBM land and that really frustrates me. I assume though that this will improve. Postgres documentation by comparison is gorgeous. Bad - I also find the bundled client tools really unfriendly for derby compared to postgres - ij is horrible compared to psql. Of course, once you are using JDBC you can use a whole bunch of different tools, but generally it seems a lot of simple usability is lacking (eg. you have to set a special parameter on the connection just to an error message back instead of a cryptic code that you will struggle to find in documentation). Bad - One thing that concerned me greatly was the ambiguity around whether the driver was going to be released - yes, amazing, but true - originally the whole DB was redistributable as open source but not the driver to access it! Well, I think this has been fixed for the java access, but as far as I know if you want ODBC you are still NOT able to redistribute the driver. I would love to hear if this is going to change. I hope nobody working on derby takes these comments as a negative - if they are wrong I apologize, please correct me. I just wanted to give the experience of a new user starting up with derby and the first impressions. Hope it's useful to you Marek! Simon. On 5/7/05, Marek Lewczuk <[hidden email]> wrote: > Hello, > I'm using PostgreSQL (and I'm very happy with that), however I'm looking > for Java-based DBMS and Derby is a proper solution. I'm just curious how > Derby looks comparing to PostgreSQL - performance, features, license > etc. Does anyone have made such a comparisons ? > > Thanks in advance. > > ML > > |
Simon wrote:
> Bad - One thing that concerned me greatly was the ambiguity around > whether the driver was going to be released - yes, amazing, but true - > originally the whole DB was redistributable as open source but not the > driver to access it! To be fair the main (embedded) JDBC driver to access it was released under open source. I was surprised how many folks immediately used the networked JDBC driver, rather than the embedded mode. But then it was always a mind shift for folks to understand the embedded JDBC driver was the complete database engine. Client/Server is more naturally understood as it is more typical. > Well, I think this has been fixed for the java > access, but as far as I know if you want ODBC you are still NOT able > to redistribute the driver. I would love to hear if this is going to > change. Do I hear a volunteer for an open source ODBC driver for Derby? Dan. |
Daniel John Debrunner wrote: The reason that some of us always use the network JDBC driver is due to the environment we have to run in. For example, in a J2EE world, I need to be able to have my application client be able to access the same databaseSimon wrote:Bad - One thing that concerned me greatly was the ambiguity around whether the driver was going to be released - yes, amazing, but true - originally the whole DB was redistributable as open source but not the driver to access it!To be fair the main (embedded) JDBC driver to access it was released under open source. I was surprised how many folks immediately used the networked JDBC driver, rather than the embedded mode. But then it was always a mind shift for folks to understand the embedded JDBC driver was the complete database engine. Client/Server is more naturally understood as it is more typical. as my web or ejb apps. This would not be possible for the majority of J2EE app servers without a redesign of at least their application client container. The other issue is that there are a couple of problems with the embedded driver that we need to address (shreyas is working on these) that we did not encounter with the network driver. In many cases, using the embedded driver is the way to go though. Well, I think this has been fixed for the java access, but as far as I know if you want ODBC you are still NOT able to redistribute the driver. I would love to hear if this is going to change.Do I hear a volunteer for an open source ODBC driver for Derby? Dan. |
There are many network, web and ejb apps that can use the embedded
driver, if it is possible to localize the database access logic in the application server where the database is running. Also remember that it may be better to use both the embedded driver for the part of the application that can be local to the database, while at the same time providing network driver access to parts of the application that are database client/server model. Often people don't realize that both drivers can be used at the same time. The embedded driver operations don't have to pay network transmission cost, so should perform equal or better to network driver operations (the key factor is the amount of data flowing in either direction). A typical application that uses this model is one that can embed all application logic in an application or web server, and thus uses the embedded driver. But it wants to do network data gathering every once in awhile, so uses the network driver to do that. Lance J. Andersen wrote: > > > Daniel John Debrunner wrote: > >>Simon wrote: >> >> >> >>>Bad - One thing that concerned me greatly was the ambiguity around >>>whether the driver was going to be released - yes, amazing, but true - >>>originally the whole DB was redistributable as open source but not the >>>driver to access it! >>> >>> >> >>To be fair the main (embedded) JDBC driver to access it was released >>under open source. I was surprised how many folks immediately used the >>networked JDBC driver, rather than the embedded mode. But then it was >>always a mind shift for folks to understand the embedded JDBC driver was >>the complete database engine. Client/Server is more naturally understood >>as it is more typical. >> >> > The reason that some of us always use the network JDBC driver is due to > the environment we have to run in. For example, in a J2EE world, I > need to be able to have my application client be able to access the same > database > as my web or ejb apps. This would not be possible for the majority of > J2EE app servers without a redesign of at least their application > client container. > > The other issue is that there are a couple of problems with the > embedded driver that we need to address (shreyas is working on these) > that we did not encounter with the network driver. > > In many cases, using the embedded driver is the way to go though. > > >> >> >>>Well, I think this has been fixed for the java >>>access, but as far as I know if you want ODBC you are still NOT able >>>to redistribute the driver. I would love to hear if this is going to >>>change. >>> >>> >> >>Do I hear a volunteer for an open source ODBC driver for Derby? >> >>Dan. >> >> >> |
Mike Matrigali wrote: > There are many network, web and ejb apps that can use the embedded > driver, if it is possible to localize the database access logic in > the application server where the database is running. agree > > Also remember that it may be better to use both the embedded driver > for the part of the application that can be local to the database, > while at the same time providing network driver access to parts of > the application that are database client/server model. Often people > don't realize that both drivers can be used at the same time. The > embedded driver operations don't have to pay network transmission > cost, so should perform equal or better to network driver operations > (the key factor is the amount of data flowing in either direction). > utilize an application client to access DatabaseA and also have web/ejb apps access DatabaseA, I need to use the network driver as today with the current implementation of most application clients. Similar scenario is true for clustered scenarios. I am not saying you cannot use the embedded driver, just there are some legit reasons why it does not meet everyone's needs. > A typical application that uses this model is one that can embed > all application logic in an application or web server, and thus uses > the embedded driver. But it wants to do network data gathering > every once in awhile, so uses the network driver to do that. > > Lance J. Andersen wrote: > >> >> >> Daniel John Debrunner wrote: >> >>> Simon wrote: >>> >>> >>> >>>> Bad - One thing that concerned me greatly was the ambiguity around >>>> whether the driver was going to be released - yes, amazing, but true - >>>> originally the whole DB was redistributable as open source but not the >>>> driver to access it! >>> >>> >>> To be fair the main (embedded) JDBC driver to access it was released >>> under open source. I was surprised how many folks immediately used the >>> networked JDBC driver, rather than the embedded mode. But then it was >>> always a mind shift for folks to understand the embedded JDBC driver >>> was >>> the complete database engine. Client/Server is more naturally >>> understood >>> as it is more typical. >>> >>> >> The reason that some of us always use the network JDBC driver is due >> to the environment we have to run in. For example, in a J2EE world, >> I need to be able to have my application client be able to access the >> same database >> as my web or ejb apps. This would not be possible for the majority >> of J2EE app servers without a redesign of at least their application >> client container. >> >> The other issue is that there are a couple of problems with the >> embedded driver that we need to address (shreyas is working on these) >> that we did not encounter with the network driver. >> >> In many cases, using the embedded driver is the way to go though. >> >> >>> >>> >>>> Well, I think this has been fixed for the java >>>> access, but as far as I know if you want ODBC you are still NOT able >>>> to redistribute the driver. I would love to hear if this is going to >>>> change. >>>> >>> >>> >>> Do I hear a volunteer for an open source ODBC driver for Derby? >>> >>> Dan. >>> >>> >>> > |
Free forum by Nabble | Edit this page |