Re: Getting started - Interfacing questions - Mailing list pgsql-novice

On Mon, Mar 07, 2005 at 09:12:53AM -0500, Sean Davis wrote:

> ----- Original Message -----
> From: "David" <dbree@duo-county.com>
> Sent: Sunday, March 06, 2005 2:48 PM

> >Thanks for the reply.  This is my first _reply_ to the list, and IIUC,
> >this list advocates replying to both the list and individual.  If I'm in
> >error, please let me know.
>
> You are not in error. : )

It just seems so strange to hit "g" (Mutt).  I'd get a very strong
chastizing for doing this on most lists  But.. when in Rome..  :)

> >>If I were you, I would build a
> >>"business logic" component, allowing for querying, inserting, updating,
> >>deleting.  Once you have the interface to the database, you can build a
> >>controller for the application.

> >With the above and below suggestions, I take it you suggest building the
> >interfacing into two separate modules, so to speak.. one for inputting
> >and one for outputting.  For the above, would it be best to create an
> >app or could all this be done from within psql, or another tool?

> Most of the higher level languages make available (often very powerful)
> methods for interacting with a database.  Choose the language you want to
> use (perl, php, python, java) and then learn about the methods for
> designing web-based applications in that language.  The choice of language
> will affect how one designs such an application.

OK.  I may be a little dense here, but I take it you're recommending
that perhaps it would be best to write a stand-alone application rather
than interfacing from one of the PL interfaces?

> It will generally NOT
> involve using psql.

That's actually what I was wondering about.  I have been reading the
archives from NOVICE, ADMIN, and USER(?), and was under the impression
that many were actually relying upon psql to do all their work.

This next statement may belong further down, but I'll insert it here..

What I'm looking toward is having the record data input into a form, and
then INSERT'ing the data into the correct table if it's accepted for
commit by the user.  (This was the gist of the discussion in a very
recent thread on one of the lists..  Again, I'll be the only one using
it, and although a bit cumbersome, I _could_ do this from an SQL INSERT
command.

I've looked at some of the general interfaces ( I haven't reviewed Mr De
Soi's interface yet), (hope I got his name right) - I have installed
pgaccess and looked into a couple of others - but there just seems to be
a layer of abstraction with all the ones I've looked at so far.  That
is, although they seem to be able to do some "keen" stuff, it just makes
it so much clearer to have a menu with an option that says, "Add a
transaction" or some such to add a record. It could be that I'm just not
familiar enough with what they can do, however.

> And, in the world of web-based applications, you
> really can't separate your logic into "input" and "output" because of the
> "statelessness" of the web interaction.

OK.  I thought you perhaps meant to write one application containing the
INSERT's, UPDATE's, etc, and then write another to handle the queries.

> Again, pick the language (php is
> probably the easiest to get going with, but if you already have experience
> with one of the other languages, use the language of most comfort instead)
> and then learn how to do web and database programming with that language.

I've never tried anything with php, perl, or python, but I've thought I
should become familiar with at least one.  I've been leaning toward
python.  Most of what I've dealt with in the past several years has been
"C".

In making my choice of the language and interfacing tools, if it were
possible, I'd like to avoid having to install a big lot of things I'd
not need for anything else (although I do have several things like this
already).  For example, the php-based front-ends require apache.  It
just seems that in my case, at least, it's asking a lot to install
apache on a machine that will never do any web-serving elsewhere in
order to access a local database -- but -- perhaps the same could be
said for using postgresql on a database that might see 300 entries at
most, but I "wanna do it"  :)