![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
Looking at the list of free databases on Wikipedia, Virtuoso Universal Server, Firebird, PostgreSQL, and Microsoft SQL Server Express Edition seem the most likely candidates. Do people here have any advice, either about those four, or about ithers I should consider? |
#3
| |||
| |||
|
|
- Access from Java, presumably by JDBC. - Persistance (on-disk storage), at least for development - For production, I may need something embedded, residing in memory only, for use in an applet. I realize that may mean I'll need to swich systems between initial development and production, but if one solution works for both, so much the better. - Referential integrity (including column-level contraints) and a GUI for setting up the schema would be very nice. They're not absolutely essential, but part of the purpose is to re-learn the use of such tools. Many years ago, managing a Sybase enterprise database (with appropriate tools) was part of what I did, and maybe I'm spoiled. - Zero cost. At least for now, I'm a hobbyist on a math teacher's salary. - If there's really anything worth learning by suing an object- oriented database, I'd like to learn it. - Sored procedured and SQL extentions to write them would be a big plus. |
#4
| |||
| |||
|
|
First, let's start with what I can easily do without: I don't need high performance. The amount of data I'll be dealing with is quite low, and so is the number of transactions. Accessing flat files from disk with no ongine at all would not be too slow for this application, it would just be annoying for other reasons. What I do need (and/or want): - Access from Java, presumably by JDBC. - Persistance (on-disk storage), at least for development - For production, I may need something embedded, residing in memory only, for use in an applet. I realize that may mean I'll need to swich systems between initial development and production, but if one solution works for both, so much the better. - Referential integrity (including column-level contraints) and a GUI for setting up the schema would be very nice. They're not absolutely essential, but part of the purpose is to re-learn the use of such tools. Many years ago, managing a Sybase enterprise database (with appropriate tools) was part of what I did, and maybe I'm spoiled. - Zero cost. At least for now, I'm a hobbyist on a math teacher's salary. - If there's really anything worth learning by suing an object- oriented database, I'd like to learn it. - Sored procedured and SQL extentions to write them would be a big plus. Looking at the list of free databases on Wikipedia, Virtuoso Universal Server, Firebird, PostgreSQL, and Microsoft SQL Server Express Edition seem the most likely candidates. Do people here have any advice, either about those four, or about ithers I should consider? I have what I believe to be a complete list of open source relational |
#5
| |||
| |||
|
|
On 09.07.2007 04:32 dvdavins (AT) pobox (DOT) com wrote: - Access from Java, presumably by JDBC. - Persistance (on-disk storage), at least for development - For production, I may need something embedded, residing in memory only, for use in an applet. I realize that may mean I'll need to swich systems between initial development and production, but if one solution works for both, so much the better. - Referential integrity (including column-level contraints) and a GUI for setting up the schema would be very nice. They're not absolutely essential, but part of the purpose is to re-learn the use of such tools. Many years ago, managing a Sybase enterprise database (with appropriate tools) was part of what I did, and maybe I'm spoiled. - Zero cost. At least for now, I'm a hobbyist on a math teacher's salary. - If there's really anything worth learning by suing an object- oriented database, I'd like to learn it. - Sored procedured and SQL extentions to write them would be a big plus. My first reaction was to recommend Postgres because it beats Firebird at the documentation and manageability. But reading your list of requirements a bit closer (especially the "embedded" part) it might be that a Java based DBMS like H2, Derby or HSQLDB might fit your needs as well - especially as you are talking about a low volume database. H2 (www.h2database.com) is quite new but seems to have more momentum than HSQLDB currently. Derby is backed by the Apache foundation and has a solid base as well, whereas HSQLDB seems to have slowed down although Fred is still active in the project. All Java DBMS offer "stored" procedures that are implemented in Java. All three of them offer an in-memory mode which neither Postgres nor Firebird offer (and surely not MS SQL, DB2 or Oracle) Thomas |
#6
| |||
| |||
|
|
On 09.07.2007 04:32 dvdavins (AT) pobox (DOT) com wrote: - Access from Java, presumably by JDBC. - Persistance (on-disk storage), at least for development - For production, I may need something embedded, residing in memory only, for use in an applet. I realize that may mean I'll need to swich systems between initial development and production, but if one solution works for both, so much the better. - Referential integrity (including column-level contraints) and a GUI for setting up the schema would be very nice. They're not absolutely essential, but part of the purpose is to re-learn the use of such tools. Many years ago, managing a Sybase enterprise database (with appropriate tools) was part of what I did, and maybe I'm spoiled. - Zero cost. At least for now, I'm a hobbyist on a math teacher's salary. - If there's really anything worth learning by suing an object- oriented database, I'd like to learn it. - Sored procedured and SQL extentions to write them would be a big plus. My first reaction was to recommend Postgres because it beats Firebird at the documentation and manageability. But reading your list of requirements a bit closer (especially the "embedded" part) it might be that a Java based DBMS like H2, Derby or HSQLDB might fit your needs as well - especially as you are talking about a low volume database. H2 (www.h2database.com) is quite new but seems to have more momentum than HSQLDB currently. Derby is backed by the Apache foundation and has a solid base as well, whereas HSQLDB seems to have slowed down although Fred is still active in the project. All Java DBMS offer "stored" procedures that are implemented in Java. All three of them offer an in-memory mode "In-memory" may be ambiguous here. All three can run in the same Java |
#7
| |||
| |||
|
|
All Java DBMS offer "stored" procedures that are implemented in Java. All three of them offer an in-memory mode "In-memory" may be ambiguous here. All three can run in the same Java Virtual Machine as the application but, unlike the other two, Derby does not allow the programmer to insist that database itself is in memory. |
![]() |
| Thread Tools | |
| Display Modes | |
| |