Re: some questions about PostgreSQL in general

On 2 Jan 2002 at 10:59, Josh Berkus wrote:

Hi Josh,

<lots of snips>

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

well, once it was up and running, most of the work was innovation. i
managed to get as much support out of the way as i could. i actually
enjoyed writing the app, although i had to invent lots of wheels to
workaround the no-trigger no-constraint no-relation foxpro tables.

of course with postgresql having these things, life will become much
easier on this level. on another level (security, learning a new db +
language) there is enough to keep me busy for a year or two :)

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

OK. Frank Bax said the same, i guess we'll go for links.

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

yes, that's too bad indeed. support is hard to find over here, we're
located in the southern part of the netherlands.

> > 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.

yes, i know. i don't know much about firewalls, SSL, etc. (my network
background is mostly NDS, netware, IPX), the best decision is IMO to
consult an external company for the setup and have another one audit
for security. that gives me more time to focus on the central issues
like programming, db design etc.

> Yes.

great!

> 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.

well, i guess i'm lucky: we don't use windows apps for business
critical apps. the main app was in clipper 5.3b which is very stable.
the reason we dump it, is that it's language oriented, not db oriented,
and it's no longer developed.

> 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".

OK, i have (and already had) that etched into my mind. we had a 2 year
pre-build stadium in which we (management team + management) evaluated
our company and what we expect from our systems.

> 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

thanks, i'll have a look.

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

after some lurking on the postgresql mailinglists there seem to be a
few items in postgresql which should be avoided, like the array
datatype and BLOBs. i guess it would be good to keep the design of the
db as straightforward and elegant as possible and avoid more exotic
features...

> > 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.

budgest is of course always an issue, but not in terms of buying
software. we have decided to go "free-beer-plus-free-speech" all the
way. so not only for the dbms, but also for the development
environment.

as for the development time, maybe it's a good idea to build a more
sophisticated front-end for the power users in Java, and a quick-and-
dirty HTML frontend with PHP. no offence meant, maybe in the end it
will be PHP only.

--
Jules Alberts