Re: PostgreSQL Advocacy, Thoughts and Comments - Mailing list pgsql-general

Further to this post, what might actually work is to convince O' Reilly
(since they have PostgreSQL book/s) to do some articles like they have
for PG, but making full use of the PG database.  For instance, building
a simple data-warehouse using PG.  Articles that show off an OSS
product/project in a clearly enterprise light in a step-by-step
fashion.  There have been so many articles on DB design using MySQL.
How about an article on DB design using all the functionality of a real
ORDBMS.

Just a few thoughts.

Cheers

T.

Tony wrote:

> HI All,
>
> I'm glad that this thread prompted some thoughtful response.   I think
> one of my main points I was trying to make, Jason hit the nail on the
> head.  The article to which I was referring uses a great example which
> I have experienced many times before, but in order to grasp this, PHP
> et al, must be thought of as a scripting language which crosses many
> corporate boundries, and it is easy to assume that it's primary use
> (simple web site back ends) are the only thing to discuss.  But the
> situation has changed enourmously since the release of PHP v4.  Now
> many consultant/developer/sys-admins like myself are going to client
> site on a contract (this is especially true in the UK, I can't speak
> for anywhere else) and finding complex stocktrading systems, inventory
> systems, CRM systems, and others, all written in PHP backed by MySQL.
> Whether this is right or wrong, good choice or bad choice is not what
> I'm interested in debating.   The point is that when these systems
> where architected, the developers used MySQL not because they were
> dumb, but because many of them develop awesome code and can get around
> most problems in the code, with a little ingenuity.  Many simply do
> not have the insight into the potential benefits of *proper* RDBMS can
> offer.   Had they had the benefit of such knowledge the code they have
> written would be faster (in DB) and more legible. Sadly often the
> developers are the only source of DBA for some of these companies.
>
> The second scenario, is with admin systems, written by people like
> myself for companies, whether they be simple or complex systems, that
> are intended as a temporary work around to an immediate problem.  In a
> very short space of time the stop-gap application you had written to
> sort out the immediate problem quickly becomes a core business
> application (I recently returned to a site after not being there for
> two years and the temporary address book/ email system that I knocked
> up in an afternoon was not only still being used, but now relied upon
> heavily).
>
> So on to my point, MySQL guys will happily say "Hey, we're not saying
> that the features MySQL is missing aren't important, and we're working
> towards them, but in the meantime these issues can be worked around
> like this....."  and happily play the whole thing down.  Many LAMP
> developers aren't aware of the benefits of stored procedures, of
> triggers and other good stuff. Like myself, if they were aware how
> much easier life could be if these things were accessible to them,
> they'd probably be converts too.
>
> There is not enough emphasis put on the basic importance of these
> functions in PG.  Someone needs to standup and say "Hey, look how this
> can simplify your programming lives"  until I started using
> Druid/Postgres, I had no idea why I needed triggers or what a cascade
> effect did, or why I might want one.
> The Linux  community has grown  at least in part because it has
> educated  potential users and journo's to its benefits.  I believe if
> the PG advocacy team did the same, then it would attract many more
> serious LAMP developers.
>
> Like Linux vs. Windows, PG has an awful lot going for it in respect to
> MySQL, so why not crow about it.  It needs to be pointed at a crowd
> that are DB novices, they need to be told why PG is worth the
> time/knowledge investment, because anyone who reads the MySQL site,
> will come away with the impression that the Trigger, Stored Procs, and
> other things are a luxurious overhead not necessary for getting the
> job done.
>
> I'd gladly help out with such a paper, but find myself in the sad
> position of my prose being open to attack due to my newbieness in the
> DB world and not able to speak authoratatively on the subject.
>
> Have a think, I'd like to know if others agree.
>
> Cheers
>
> T.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>               http://archives.postgresql.org