I have been running the SapDB on solaris for almost a year now. It is running in a production environment with PHP. I would have to agree with the other posters as far as the learning curve, it was fairly steep. The ends definately justify the means, however. Now that they have the 64-bit version for solaris released, the performance is even better. The database it holds is approximately 1.1 Gb. It has numerous tables that have two or more primary keys. It also has a plethora of stored procedures. Performance has been very acceptable. Albeit not as fast as Mysql, but once the system expanded beyond the first 2 tables, Mysql had a real problem managing it. The decision to move to sap was based on a simple method. Was the database shaping the code, or the shaping the database. With Mysql the limitations of the database (lack of sub querys being the most annoying) were having a profound impact on the complexity of the code. The move to sap allowed a much simpler, more efficient code base. The database is not quite as fast, but the performace hit there is severely outweighed by the performance gain from removing several hundred lines of php code. Additionally, since the database structure was simplifiable, report generation also became much easier. Realistically you have to compare the future needs of your data and your user base. Everyone here is worried about transaction support, etc... The real issue is whether the time invested circumventing the pitfalls of your particular database (Mysql,PG,Sap,Oracle) are going to outweigh the advantages it brings to the table. I suggest installing several databases, and loading a sample set of your data. Then try to retrieve the data in ways that the resulting application would. The database that makes this process easiest is your best choice.
Slashdot Mirror
I have been running the SapDB on solaris for almost a year now. It is running in a production environment with PHP. I would have to agree with the other posters as far as the learning curve, it was fairly steep. The ends definately justify the means, however. Now that they have the 64-bit version for solaris released, the performance is even better. The database it holds is approximately 1.1 Gb. It has numerous tables that have two or more primary keys. It also has a plethora of stored procedures. Performance has been very acceptable. Albeit not as fast as Mysql, but once the system expanded beyond the first 2 tables, Mysql had a real problem managing it. The decision to move to sap was based on a simple method. Was the database shaping the code, or the shaping the database. With Mysql the limitations of the database (lack of sub querys being the most annoying) were having a profound impact on the complexity of the code. The move to sap allowed a much simpler, more efficient code base. The database is not quite as fast, but the performace hit there is severely outweighed by the performance gain from removing several hundred lines of php code. Additionally, since the database structure was simplifiable, report generation also became much easier. Realistically you have to compare the future needs of your data and your user base. Everyone here is worried about transaction support, etc... The real issue is whether the time invested circumventing the pitfalls of your particular database (Mysql,PG,Sap,Oracle) are going to outweigh the advantages it brings to the table. I suggest installing several databases, and loading a sample set of your data. Then try to retrieve the data in ways that the resulting application would. The database that makes this process easiest is your best choice.