Re: Progress and Questions

Richard Broersma Jr. wrote:

>  Another example of a client interface is pgDesigner.  It allows a
> database designer/administrator to develop a graphical representation
> of a database "schema" design.  pgDesigner would then connect to the
> PostegreSql server, create a new database and then pass all of the
> sql commands that would generate the database schema from the initial
> graphical design.

Excellent information -- and I think I understand what it means, now.

emc: > > Is there a reason to pick one of those languages over another?

> It depends.  Various languages are useful for different purposes.  Do
> you want your client interface to be a web page, or a text based
> program, or a graphically user interface?
>
> Depending on which you choose, the sets of available languages is
> reduced.

I'd say a text-based program is my preference at this point.  It would need
to display menus, offer a series of prompts for the user to supply
information, and offer a range of report options.

Enough of this answer has challenged assumptions I didn't even know I had
that I want to verify something about a text interface vs graphical
interface.  When a user is entering data into a form in a program like
Access, there's a pretty window that pops up to accept the data.  The user
can tab from field to field, add data and edit it at length, then click a
button to send the data into the database.  Apart from accessing the form
(and ending the input session) via button clicks, is this operation the sort
of thing a text-based interface can manage?

> I hate to complicate things for you here.  But there are potentially three
> languages that you would have to learn.  1st. SQL,  2nd. RDBMS procedural
> language, 3rd. Client interface Programming Language.

Heh.  It got complicated all on its own; you're clarifying.  It's not your
fault that what you're clarifying isn't, itself, simple.

   - emc