Forum OpenACS Q&A: Re: OpenACS assessment...
MySQL has matured greatly since the days in which the "Why not MySQL?" article and the subsequent discussion were written. They do have an ACID-compliant backend (InnoDB) - not written by Monte and the gang, of course. The article's very much out of date. On the other hand, it's a good reference for making clear why we originally chose PostgreSQL as our open source RDBMS back end rather than MySQL.
If MySQL becomes SQL92 compliant (how are they coming on subselects?) then there's every likelihood that OpenACS *could* be ported to MySQL.
Yet I doubt there's going to be much enthusiasm for the idea. PostgreSQL continues to improve at a very rapid pace. While MySQL is more widely used, it would be incorrect to say that PostgreSQL is not widely used, and it is still a more mature and robust RDBMS.
And most importantly ... the cost of maintaining a third database implementation would be high, and we certainly will not abandon our OpenACS/PG base of users. We have better things to do with our time.
If we were to undertake the support of a third RDBMS, one could make a much stronger argument for supporting MS SQL Server than MySQL.
above.
MySQL has matured greatly since the days in which the "Why not
MySQL?" article and the subsequent discussion were written. They do
have an ACID-compliant backend (InnoDB) - not written by Monte and
the gang, of course. The article's very much out of date. On the
other hand, it's a good reference for making clear why we originally
chose PostgreSQL as our open source RDBMS back end rather than
MySQL.
If MySQL becomes SQL92 compliant (how are they coming on
subselects?) then there's every likelihood that OpenACS *could*
be ported to MySQL.
</blockquote>
On that front. In my area we have a new person that is becoming
involved in the local LUGs and User Groups. He is an
employee of MySQL. He seems a very agreeable person. I had
a breif email discussion with him about attending a OpenACS
social or such and making himself available for a discussion of
what would be needed in MySQL to run OpenACS. He was aware
of the 'Why Not MySQL' page on OpenACS and appeared to be
more than willing and to follow up on it. Now if any OpenACS
people are willing to pay a visit to Northeast Ohio we might be able to
set something up. Perhaps even to just create a new and updated
'Why Not MySQL' page.
<blockquote> Yet I doubt there's going to be much enthusiasm for the idea.
PostgreSQL continues to improve at a very rapid pace. While MySQL
is more widely used, it would be incorrect to say that PostgreSQL is
not widely used, and it is still a more mature and robust RDBMS.
</blockquote>
This is agreed here. PostgreSQL is a wonderful database and
still has a lead in maturity with MySQL. MySQL is more widely
deployed and therefore people have the 'Why are you not using
MySQL' attitude when it comes to Open Source projects. This
is enough of a ``problem'' that it comes up about every 3 months
or so on the list.
<blockquote> And most importantly ... the cost of maintaining a third database
implementation would be high, and we certainly will not abandon
our OpenACS/PG base of users. We have better things to do with
our time.
If we were to undertake the support of a third RDBMS, one could
make a much stronger argument for supporting MS SQL Server
than MySQL.
</blockquote>
I disagree slightly. I think the better argument is to consider supporting
MySQL. MySQL can not be used because it doesn't have the features
need by OpenACS. I believe it can be said, with little argument, that
having MySQL support OpenACS's database requirements would only
improve it and make in a more attractive project. I think, but I don't
know, that the people behind MySQL might be willing to work with
another Open Source project.
Since OpenACS has to deal with the question of not supporting MySQL
and we have some valid reason for not doing, I think we have the
option of engaging MySQL and discussing it with them. If they choose
to not work with OpenACS we'll have good reasons. If they choose
to listen and work to add the required bits that are needed it would
only improve a highly visable and widely deployed Open Source project.
