Skip site navigation (1) Skip section navigation (2)

Optimal Postgres Development Process, Software

From: "Roger Rasmussen" <pgsqln00b(at)australiamail(dot)com>
To: pgsql-novice(at)postgresql(dot)org
Subject: Optimal Postgres Development Process, Software
Date: 2006-08-16 06:26:21
Message-ID: 20060816062622.13B111BF28E@ws1-1.us4.outblaze.com (view raw or flat)
Thread:
Lists: pgsql-novice
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/


Responses

pgsql-novice by date

Next:From: Harpreet DhaliwalDate: 2006-08-16 06:39:48
Subject: Re: [NOVICE] DB insert Error
Previous:From: Michael FuhrDate: 2006-08-16 05:54:19
Subject: Re: [NOVICE] DB insert Error

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group