Optimal Postgres Development Process, Software

Operationsengineer,

Thanks for the feedback.

To be honest, I'm not at all excited about having to use a web
browser as a means of data entry. Compared to an access frontend,
they are clunky and slow. I suppose that they might be able to
achieve some security through password and IP restriction? Again, I
am a novice so help me out here. But a browser interface would be
an absolute last resort. Rather than use a browser, it would be
preferable to do something similar to the procedure outlined here
with PG + Access97:

http://sevasoftware.com/access/index.html#Reasonforporting

I'm curious to hear from someone who had similar priorities, tried
a few different things, found something that worked well, and can
explain how to map from a typical access process to a postgres +
whatever process.

For example, when I hear that people can do all the backend table
creation stuff via the command line, I'd love to know how they can
see everything they have created and test that it works, as you can
easily do in Access. As I said, a mapping from Access to PG +
whatever. Surely it shouldn't be too hard for someone who made the
transition from Access to PG to give a brief explanation of what
the 8 steps in my database creation process are in their PG
environment. Even someone who just has a good grounding in PG and
making solid internal business database applications should be able
to do it.

It's not as if my needs are unique. Someone upgrading from access
needs the scalability, robustness, ability to handle complexity and
ease of interfacing that postgres provides. Databases used
internally by businesses tend to have a few users performing _lots_
of data entry/transactions/reporting, rather than lots of users
performing small chunks of work. There has to be some sort of open source front end solution that is tailored to this type of work, where a mouse is touched only when absolutely necessary.

And I don't mind waiting a week or more before I make an
interface/language decision. IME it's rarely a good idea to dive in
at the deep end without getting a good sampling of opinions from
those who have already gone before. What's an extra week (or
month!) if 6 months (or 6 years) down the track you suddenly
realize that you have made the wrong decision and need to rework
everything? For example, I took a good 3 weeks or more to decide on
postgres. If you had asked me early last week which backend I was
going to use, I would have told you MySQL.

> make the interface decisions and then decide on a
> language that can get it done and *get started*. stay
> in touch here and with the forums, newsgroups, mailing
> lists, etc. for the language / framework that you
> choose.
>
> good luck.

--
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/