Optimal Postgres Development Process, Software - Mailing list pgsql-novice
From | Roger Rasmussen |
---|---|
Subject | Optimal Postgres Development Process, Software |
Date | |
Msg-id | 20060816062622.13B111BF28E@ws1-1.us4.outblaze.com Whole thread Raw |
Responses |
Re: Optimal Postgres Development Process, Software
|
List | 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 typeof 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/
pgsql-novice by date: