Greetings, all.



This has been fascinating so far. I've learned to do the basic stuff -
build tables, add columns, insert rows, perform queries, and establish
views. I did that by going through the online manual a number of times
through the end of "Advanced Features." I've gotten midway through
"Functions and Operators" once, and it'll take several more passes through
these chapters before I can say I've begun to learn them.



My experience has been that my first pass results in complete confusion. I
couldn't even repeat what I've read, much less claim to understand it. The
second and third passes come with a glimmer of hope and a tentative grasp on
the material. By the fourth and fifth passes, I'm able to work with the
tools as a novice. I'm sure that a few more passes will reveal that I
overlooked some key concepts so far, and that'll help to shore up gaps in my
knowledge.



So, that's my progress so far. Thanks to everyone for helping me get to
this point!



Here are my questions, one of which might be less technical (and more
philosophical) than the other:



I find that (as I construct the tables, columns, queries, and views) I want
a refined interface for inputting data and looking at query outputs. I'm
going to assume that this chomping-at-the-bit is common. Is there any value
to thinking ahead from the database structure to the ways a client will
interact with it?



The manual told me that a variety of client interfaces already exist, but
that it's most common for the client interface to be built from scratch.
Glancing ahead at the "client interface" section, I saw that the interfaces
are written in another language entirely. I flinched.



This is my first foray into anything like programming; to date, I have been
the most common sort of end-user. I am daunted by the prospect of learning
yet another language once I'm through this one. The broad range of
available languages is just the first hurdle, and already I don't know
enough to make a sound decision. Is there a reason to pick one of those
languages over another? I don't even know what to consider in making a
choice of what to tackle.



- emc

On Sun, Sep 03, 2006 at 11:02:17 -0500,
"Eric M. Cherry" <cherry_eric@sbcglobal.net> wrote:
>
> I find that (as I construct the tables, columns, queries, and views) I want
> a refined interface for inputting data and looking at query outputs. I'm
> going to assume that this chomping-at-the-bit is common. Is there any value
> to thinking ahead from the database structure to the ways a client will
> interact with it?

You certainly want to decide what kinds of questions you want to be able to
answer and make sure it is possible to do that with your design.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

> The manual told me that a variety of client interfaces already exist, but
> that it's most common for the client interface to be built from scratch.
> Glancing ahead at the "client interface" section, I saw that the interfaces
> are written in another language entirely. I flinched.

Well most of the client interfaces that already exist are very specific in the functionality they
provide. PgAdmin III is an example of a client interface to the postgresql database. Notice that
its main purpose is for database administration. It probably would not be well suited as a client
interface for an banking ATM machine for example. 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.

In your case you may want to develop a program that a client of yours can use to (lets say)
engineer, estimate, and schedule a project/product of their interest. This "program" would
comprise of a Database repository and client front end. Generally, the types of RDBMS(for
repository) and programming language(for front end) are choices that developer will make. I
imagine that developers make use the tools they are most experienced with.

> 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 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.

The good this about Postgresql is that you could potentially reduce your learning curve by
choosing the same Language for both the RDBMS and the client interface. Although I would not
recommend this. :-)

Regards,

Richard Broersma Jr.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

You might get some better suggestions if you provide more details on
your goals and requirements. While learning SQL is a good thing, I
think there are much more accessible tools for a beginning programmer
who needs a database and custom interface. Have you looked at tools
like FileMaker and 4D?


On Sep 3, 2006, at 12:02 PM, Eric M. Cherry wrote:

> This is my first foray into anything like programming; to date, I
> have been the most common sort of end-user. I am daunted by the
> prospect of learning yet another language once I’m through this
> one. The broad range of available languages is just the first
> hurdle, and already I don’t know enough to make a sound decision.
> Is there a reason to pick one of those languages over another? I
> don’t even know what to consider in making a choice of what to tackle.



John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

> I find that (as I construct the tables, columns,
> queries, and views) I want
> a refined interface for inputting data and looking
> at query outputs. I'm
> going to assume that this chomping-at-the-bit is
> common. Is there any value
> to thinking ahead from the database structure to the
> ways a client will
> interact with it?

yes, although, most of the time each facet will be
independent. iow, you won't have to redo the back end
when if you were to change the interface end.

> The manual told me that a variety of client
> interfaces already exist, but
> that it's most common for the client interface to be
> built from scratch.
> Glancing ahead at the "client interface" section, I
> saw that the interfaces
> are written in another language entirely. I
> flinched.

decision time. database development isn't trivial.
you will probably not ever stop learning new languages
or new functionality until you stop developing
applications.

like it or not, this just comes with the territory.
there is lots to learn - the sooner you get started,
the more time you have to learn this information. do
be patient with yourself and pace yourself.

if you don't want to constantly learn new things,
perhaps db application development isn't your thing.

based on your dedication and excitement working with
pgsql, i think it migh tbe your thing, you just have
to get comfortable with the process.


> This is my first foray into anything like
> programming; to date, I have been
> the most common sort of end-user. I am daunted by
> the prospect of learning
> yet another language once I'm through this one. The
> broad range of
> available languages is just the first hurdle, and
> already I don't know
> enough to make a sound decision. Is there a reason
> to pick one of those
> languages over another? I don't even know what to
> consider in making a
> choice of what to tackle.

1. do you require cross platform OS compaitibility?
2. do you want a free and open source approach?
3. do you want something relatively easy to get into,
even if not the best programmin gapproach?
4. is your application going to be web based?

all my answers were yes, and i ended up with php.

in addition to learning about pgsql, i had to learn
sql, html, css (cross browser compatibility
programming is the WORST experience to date), php,
Manuel Lemos' forms class, ADOdb db abstraction layer,
minimal javascript and the DOM (a close second in
HORROR compared to css due to shoddy and inaccurate
PHP/DOM related tutorials).

i'm sure i've missed some things. i'm no expert in
any of the above, but i knew enough at one time to
have developed everything i've developed to date. i
can always look back on my code to refresh my memory.

i'm currently learning some ruby and ruby on rails b/c
it is a more powerful programming language and rails
is a framework that can be very useful in some
circumstances. ruby can be used to create cross
platform desktop apps from an executable file.

cool stuff.

i'd recommend reading up on ruby right now. some of
the OOP stuff can be mind bending when *you* actually
have to plan out the objects, especially when the
concepts are new -as they are for me.

good luck.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

operationsengineer1 wrote:

> decision time. database development isn't trivial.
> you will probably not ever stop learning new languages
> or new functionality until you stop developing
> applications.
>
> like it or not, this just comes with the territory.
> there is lots to learn - the sooner you get started,
> the more time you have to learn this information. do
> be patient with yourself and pace yourself.
>
> if you don't want to constantly learn new things,
> perhaps db application development isn't your thing.

Heh. How often does life imitate application development? Like most
things, this undertaking grew more complicated the more I delved into it.
Still, it *is* exciting enough that I'm keen to continue.

> 1. do you require cross platform OS compaitibility?
> 2. do you want a free and open source approach?
> 3. do you want something relatively easy to get into,
> even if not the best programmin gapproach?
> 4. is your application going to be web based?
>
> all my answers were yes, and i ended up with php.

For myself, I don't have a dog in most of those fights. I'd be happy with a
product that works in one platform, without needing to be web-based, etc. I
can see the benefits to having all four be yes, though.

> in addition to learning about pgsql, i had to learn
> sql, html, css (cross browser compatibility
> programming is the WORST experience to date), php,
> Manuel Lemos' forms class, ADOdb db abstraction layer,
> minimal javascript and the DOM (a close second in
> HORROR compared to css due to shoddy and inaccurate
> PHP/DOM related tutorials).
>
> i'm currently learning some ruby and ruby on rails b/c
> it is a more powerful programming language and rails
> is a framework that can be very useful in some
> circumstances. ruby can be used to create cross
> platform desktop apps from an executable file.


I'm told that even the most stalwart heroes wish they'd stayed home when
they see the size of the dragon. Thanks for the guidance!

- emc


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

Most people have listed languages that they personally like because of the nice features that each
as in one area or another. However, from the threads that I've read, posters suggest using the
language that you are most familiar with. In my case, I wanted to learn PHP, but since my primary
effort/interest is learning PostgreSQL and SQL in general I've placated myself to using MS-Access
+ ODBC as a front end in the mean time.

However, one point that worries me about using MS-Access is that I don't want to learn building
the front-ends the Access way (i.e. bound forms) if it doesn't conform to any widely accepted
design philosophy used by most other technologies. My intuition is that other technologies simply
passes SQL command to the back-end database rather than binding a form to a query or table. The
good news is that Access will allow you develop front-ends either way.

Perhaps a seasoned application developer could shed some light on any "more conventional way" for
attaching a front-end to the back-end for the both of us.

Regards,

Richard Broersma Jr.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster