From: | Brendan Jurd <blakjak(at)blakjak(dot)sytes(dot)net> |
---|---|
To: | |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: PostgreSQL Advocacy, Thoughts and Comments |
Date: | 2003-12-01 05:22:07 |
Message-ID: | 3FCACFFF.9030609@blakjak.sytes.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hello,
I'd just like to add that this thread is perfectly aligned with my own
experiences on the DB front.
When I started out as a developer, I was familiar with the concepts of
good database design, but *not* with the range of DBMSs available, and
their respective advantages and disadvantages. I started using MySQL
because it was popular, fast, free and (sort of) easy to set up. Then
my major project, a payroll management system, previously PHP/MSSQL,
needed a new environment established very quickly. I used MySQL because
time was short and it was what I knew. To get around the lack of proper
foreign key constraints I did crazy things like manually maintaining a
table of "foreign keys" and enforcing them from PHP.
When the client on that project hired a new sysadmin, the sa took one
look at the system and said "Uhh, dude. Do you know anything about
postgres?"
I'd heard of postgres but didn't really know anything about it. After
having the sysadmin tell me about postgres' capabilities, and checking
out the manual for myself, I realised that I'd been barking up the wrong
proverbial tree for months. So we migrated the system to postgres
earlier this year, and I couldn't be more pleased with it. The
immediate payoff of having referential integrity enforced properly was
wonderful, but the advantages just kept on coming. I started using
postgres functions and views to shift more of the work of "organising
data" over to the piece of software that *should* be handling it. Some
of those views enabled me to chop vast tracts of superfluous PHP code
out of the system. The more I used postgres, the more I came to
understand -- this is the way it ought to be.
BJ
Rick Morris wrote:
> 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.
>
>
> So true! I am in the U.S (Florida), and I am seeing the same thing
> here. Starting around 2000, many fairly complex, mission-critical
> PHP/MySQL apps were developed, which are just beginning to surface. We
> all know how prevalent PHP and MySQL became overnight, but how many of
> us realize that it was not just used for 'lightweight' applications?.
> Imagine how big a problem all these PHP/MySQL applications are going
> to become over the next few years. I have had the dubious pleasure of
> moving a few of these from MySQL to PostgreSQL already (Yes, financial
> systems using MySQL's unconstrained numeric types!!), and I shudder to
> think about all the companies that might end up with *years* of
> poorly-constrained data.
>
>> 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.
>
>
> Most medium/small business managers don't even know there is a
> difference between the two.
>
> <snip>
>
>> 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.
>
>
> You're not doing too badly, really. Your writing is good and clear,
> and your knowlege is well above the typical corporate IT magazine hack
> ;-).
>
> Regards,
>
> Rick Morris
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2003-12-01 05:58:06 | Re: export FUNC_MAX_ARGS as a read-only GUC variable |
Previous Message | Alex Satrapa | 2003-12-01 05:15:40 | Re: Pg module for Perl |