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