Обсуждение: General Q's

> I am undertaking a development which typically relies on the type of
> functionality that can be found at Joomla (www.joomla.com
> <http://www.joomla.com/>) and Drupel (www.drupel.com

Drupal.

>
> Both Joomla / Drupal are making their databases work with Postgsql using
> an abstraction layer.
>

Correct.

> Could you advise on the following?
>
>     * Is there a project to create MySQL compatibility for Postgresql? I

No. Thank god.

>       am not technical so you will need to explain as if I am a 3-year old!
>     * What other Open Source solutions which support the similar type of
>       functionality found on Joomla and Drupal work with Postgresql?

Those are the two I know best. We have several extremely high profile
customers that use Drupal & PostgreSQL with great success.

Joshua D. Drake

Joshua D. Drake wrote:
>
>>     * Is there a project to create MySQL compatibility for Postgresql? I
>
> No. Thank god.
>

Just think of all those potential customers you could be missing JD :-)

http://pgfoundry.org/projects/mysqlcompat/

/D

David wrote:
> Both Joomla / Drupal are making their databases work with Postgsql using an
> abstraction layer.

Nothing wrong with that.

> Questions - re MySQL/ Postgresql/Joomla/Drupel
>
> Could you advise on the following?
>
> *    Is there a project to create MySQL compatibility for Postgresql? I
> am not technical so you will need to explain as if I am a 3-year old!

No. Unlikely to be too - you'd need to have bug-for-bug compatibility to
make it worthwhile. At which point you might as well use MySQL.

> *    What other Open Source solutions which support the similar type of
> functionality found on Joomla and Drupal work with Postgresql?

If you're not particularly skilled in either MySQL or PostgreSQL then
I'd pick the application first and use whatever database it works best on.

You might find the following useful:
  http://en.wikipedia.org/wiki/List_of_content_management_systems
  http://www.opensourcecms.com/

For a local community site I'm working with I chose cmsmadesimple, but
both Joomla and Drupal have a lot of users.

--
   Richard Huxton
   Archonet Ltd

Dave Page wrote:
> Joshua D. Drake wrote:
>>
>>>     * Is there a project to create MySQL compatibility for Postgresql? I
>>
>> No. Thank god.
>>
>
> Just think of all those potential customers you could be missing JD :-)
>
> http://pgfoundry.org/projects/mysqlcompat/

I know you put a smiley face there but... I find that people that want
to do it the "compatible" way don't want to do it the "right" way.

I have enough trouble with people wanting to do it the right way, I
don't need to add the compatible way to the list ;)

Sincerely,

Joshua D. Drake



>
> /D
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>               http://archives.postgresql.org/
>

On Wed, 12 Dec 2007 09:01:59 -0800
"Joshua D. Drake" <jd@commandprompt.com> wrote:

> Those are the two I know best. We have several extremely high
> profile customers that use Drupal & PostgreSQL with great success.

May I ask you why they choose Postgres inspite of MySQL?

Drupal core works *nearly* painlessly with postgres but contrib
modules aren't too Postgres friendly. Mainly because the Drupal
community (as many CMS communities) is mysql centric or standard
ignorant.

Whenever I can Drupal is running on Postgres, mainly because there
are applications dealing with money inside Drupal and
a mature transaction, data integrity engine helps.

Mysql feature are starting to look comparable if you skip the gotchas
in places they will really come as an unpleasant surprise once you
get used to pg coherence. The fact that mysql runs on multiple engine
may be a pro on the *long* run. But still Postgres is a safe harbour
and it will be for some time to come.

Furthermore I find developing for postgres is easier than for mysql
since I can rely on the DB, plus I've used pgsql for longer.

In many cases I scarified portability to ease of development and it
doesn't make me feel too comfort.

I'd like support for pgsql on Drupal would be stronger anyway.
It seems that the new schema api in D6 would improve things and there
are chances that D7 will offer a better DB SPI too.
It would be nice if Postgres people will stop by drupal dev mailing
lists to help.

BTW anyone know a DB translator pgsql<->mysql just to learn from it?
What about interesting DB abstraction layers that works with postgres
and at least 2 more other DB?

--
Ivan Sergio Borgonovo
http://www.webthatworks.it

On Dec 12, 2007 12:33 PM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
> On Wed, 12 Dec 2007 09:01:59 -0800
> "Joshua D. Drake" <jd@commandprompt.com> wrote:
>
> > Those are the two I know best. We have several extremely high
> > profile customers that use Drupal & PostgreSQL with great success.
>
> May I ask you why they choose Postgres inspite of MySQL?

The two most common reasons a company chooses postgresql over MySQL
for these kinds of things are:

They already have a real db server running pgsql in house.  If you've
spent $25,000 on your data warehouse machine, and it can handle the
drupal, RT, Jira, hyperic, snort, jive, bacula, custom RoR app, etc...
databases in it's spare time, why not use it for this as well.
Building a new MySQL server for one application makes the incremental
cost much higher.

> Drupal core works *nearly* painlessly with postgres but contrib
> modules aren't too Postgres friendly. Mainly because the Drupal
> community (as many CMS communities) is mysql centric or standard
> ignorant.

Mostly they just aren't familiar with anything else.  It's not like
they hate the standards, but MySQL tends to teach bad habits, and this
means that apps developed first for MySQL tend to suffer from lots of
MySQL'isms

> Whenever I can Drupal is running on Postgres, mainly because there
> are applications dealing with money inside Drupal and
> a mature transaction, data integrity engine helps.

s/helps/is a necessity/

> Mysql feature are starting to look comparable if you skip the gotchas
> in places they will really come as an unpleasant surprise once you
> get used to pg coherence.

But the problem is it just LOOKS like they're comparable.  They're
not.  Sub selects still do pretty much only nested loop joins (i.e.
they're slow for large sets) and the query planner is dumb as a brick.
 All of the features they're adding now are fresh and new, and may or
may not work all that well.  Those same features have as much as a
decade or more of polishing and tuning in PostgreSQL.

> The fact that mysql runs on multiple engine
> may be a pro on the *long* run.

Seems to me each engine is a collection of compromises, most of which
I don't want to make.  It's like by breaking up their work power over
so many different engine products, no one engine gets enough attention
to be really outstanding.  The closest thing to a tuned, mature engine
that can handle transactions is innodb, and Oracle bought that, so who
knows where they're headed.  The falcon table handler won't be done
for at least another year or two (i.e. truly production ready).

> But still Postgres is a safe harbour
> and it will be for some time to come.

And it's not like it's just sitting still, waiting for MySQL to pass
it by.  The improvements in the last three years have been amazing in
terms of performance and capability.   and with 8.3 there are some
very interesting performance enhancements for the subset of loads that
fit in memory and have high update rates, something that mysql has
traditionally beaten pgsql at.

On Wed, 12 Dec 2007 12:43:27 -0600
"Scott Marlowe" <scott.marlowe@gmail.com> wrote:

> The two most common reasons a company chooses postgresql over MySQL
> for these kinds of things are:

> They already have a real db server running pgsql in house.  If

Any good reason for situation that don't have already big iron
deployed?

> > The fact that mysql runs on multiple engine
> > may be a pro on the *long* run.
>
> Seems to me each engine is a collection of compromises, most of
> which I don't want to make.  It's like by breaking up their work
> power over so many different engine products, no one engine gets
> enough attention to be really outstanding.  The closest thing to a

It could be.

> tuned, mature engine that can handle transactions is innodb, and
> Oracle bought that, so who knows where they're headed.  The falcon
> table handler won't be done for at least another year or two (i.e.
> truly production ready).

Yep.

> > But still Postgres is a safe harbour
> > and it will be for some time to come.

> And it's not like it's just sitting still, waiting for MySQL to pass
> it by.  The improvements in the last three years have been amazing
> in terms of performance and capability.   and with 8.3 there are
> some very interesting performance enhancements for the subset of
> loads that fit in memory and have high update rates, something that
> mysql has traditionally beaten pgsql at.

I'd like to see more hosting offering pgsql and more applications
like drupal offering a more mature support to pgsql.
Hosting is getting cheaper and cheaper and more complex and demanding
applications can be put on hosting. Exactly the kind of application
that will benefit from running on postgres.
The more hosting on pgsql, the more developer, the more applications,
the more hosting...
I can think the same in regard to python vs. php.

--
Ivan Sergio Borgonovo
http://www.webthatworks.it