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

Re: Optimal Postgres Development Process, Software

From: Glenn Davy <glenn(at)tangelosoftware(dot)net>
To: Roger Rasmussen <pgsqln00b(at)australiamail(dot)com>
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: Optimal Postgres Development Process, Software
Date: 2006-08-16 06:42:58
Message-ID: 1155710579.27691.8.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-novice
hi roger...
Sorry  havent followed this converstation from the start and Im afraid I
dont fit into the' have tried this and it works well' category, but it
DOES rate highly on my list of things to do: and might be worth you while to look - more for
generating the user interface than the schema though.

On Wed, 2006-08-16 at 01:26 -0500, Roger Rasmussen wrote:
> 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:
> 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.

In response to

pgsql-novice by date

Next:From: Harpreet DhaliwalDate: 2006-08-16 06:59:23
Subject: Re: [NOVICE] DB insert Error
Previous:From: Harpreet DhaliwalDate: 2006-08-16 06:39:48
Subject: Re: [NOVICE] DB insert Error

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