Re: Optimal Postgres Development Process, Software

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:
www.dabodev.com 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:
>
> 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.
>
>