Re: some questions about PostgreSQL in general

> hello everybody,

Hello, Jules.

> my company uses at the moment a Clipper application with foxpro
> tables,
> homemade, it's about 5 years old and has constantly been in
> development
> (innovation, extension, bugfixes). the db is rather small (500mb),
> but
> the functionality is complex (in terms of relations, also it's
> client-
> server with one central database + read-write replica's to several
> notebooks)

On Clipper/Foxpro? Must be a full-time job to keep running ...

> we have decided to go for a complete new platform and after looking
> at
> Oracle (too expensive) and some existing solutions (not flexible
> enough) we want to go for a *nix (Redhat, Debian or OpenBSD, testing
> will be done on Redhat 7.2, maybe when Woody awakens i'll switch) and
> a
> postgreSQL db. the front-end isn't decided yet, but we have decided
> to
> drop the replication and let the notebooks make a dial-in connection,
> so PHP or JDBC would seem the obvious choice. the database should
> also
> be able to either hold a lot of office documents as BLOBs or contain

I'd reccommend links to files for data integrity reasons. Postgres is
capable of either.

> links to the files themselves, which are located on a netware 4.11
> server. the client machines are win95 workstations, but HTTP access
> should also be possible.

Darn! Too bad you're not in my area. This is exactly the kind of work
my company does ...

> the db is the core of our business so it should be very stable and
> also
> very secure, because we work with medical data.

Keep in mind that DB-level (through SQL) security is only about 5% of
overall security. Network security and user management play a much
lareger role.

> my guess would be that postgreSQL is ready for the job, is this
> correct?

Yes.

> also i would be much obliged for any info about which
> version
> i should choose (the stable version or the developer version)

Start playing with 7.1.3 now, but plan your application for 7.2. It
will be ready before you finish your application. And, frankly, if you
are used to working with MS-DOS/Windows apps, the stability you get out
of a Postgres "beta" version (such as 7.2 RC1) is comparable to most
MS/Windows software "release" versions.

> and
> generally about which pitfalls i'm likely to encounter,

DB Application Design tip #1: Never, ever, ever, skimp on the
application planning stage. As a rule, every hour you cut from
necessary planning meetings and papers will equal 3-6 hours spent
debugging and/or adding "enhancements".

For more application design thoughts, Steve McConnell's Software Project
Survival Guide is good. Also see the book reviews at:
http://techdocs.postgresql.org/bookreviews.php

As for Postgres-specific pitfalls, I can't think of any. we have a
pretty robust RDBMS platform at this point.

> which
> frontends
> are "mature", etc.?

Based on your requirements above, I would reccomend Java/J2EE rather
than PHP. PHP is not designed for the same depth/complexity of security
and distributed access as Java or C++. However, if your development
budget is unreasonably constrained, you may have to choose rapid
development (PHP, Kylix/Delphi, or Python/Zope) over robustness (Java or
C++ plus XML). Postges works with all of these and a few more (C#,
anyone?) but as always, you must trade off your "wish list" vs. your
budget.

-Josh Berkus

______AGLIO DATABASE SOLUTIONS___________________________
Josh Berkus
Complete information technology josh(at)agliodbs(dot)com
and data management solutions (415) 565-7293
for law firms, small businesses fax 621-2533
and non-profit organizations. San Francisco