Skip site navigation (1) Skip section navigation (2)

Re: Application using PostgreSQL as a back end (experienced programmers

From: William Yu <wyu(at)talisys(dot)com>
To: pgsql-novice(at)postgresql(dot)org
Subject: Re: Application using PostgreSQL as a back end (experienced programmers
Date: 2005-11-16 16:02:52
Message-ID: dlfl7k$ni8$1@news.hub.org (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-novice
Bill Dika wrote:
> Furthermore, I think that if it did use a web interface, it would not be 
> nearly as responsive as it is. That is why I was thinking of not using a 
> browser. I use SQL-Ledger for my own bookkeeping. It is written in Perl, 
> uses PostgreSQL as a backend and a browser for a front end. While I like 
> the program very much and enjoy the freedom of using it as compared to 
> something like say, Quickbooks, there is a noticeable delay when loading 
> a form. This delay seems to be much less in stand alone programs that do 
> not use a browser. Or am I wrong about this? In any case your 

Basically, the issue with web-based is more of a perception/workflow 
problem than performance. Everything is submit->server does 
stuff->return results. While you can sprinkle a little Javascript to 
make the UI more responsive, using too much Javascript tends to make 
your programs hard to maintain.

At least that is how it was before. Now with AJAX, you can background 
submit data the moment your user clicks/types something and while 
they're still doing their data entry, the server is already processing 
their work to either return results faster or update the screen realtime.

A good example of this is comparing Mapquest to Google maps. Mapquest 
uses the old paradigm. You click on a map, the mapquest server 
resizes/zooms/whatever and creates a new gif for you to download. Google 
maps on the otherhand is constantly generating new data while you 
navigate allowing what appears a "windows-like" interface.

You definitely have to do much better planning to write AJAX web apps 
though. I'm still learning the nuances myself -- trying to figure out 
where's the best place to use it in my web apps. I.e. don't go overboard 
immediately and try to implement it everywhere. Just use it where the 
user perceives UI delays.

Of course, there's the idea of not bothering with AJAX and just living 
with the perceived delays. It ends up not being a big deal because (1) 
users expect such delays on the web and (2) users get used to such 
delays on the web. It was a bit of a concern when we developed our 
insurance app as 100% web-based -- users accustomed to switching to 
different pages of info instantaneously going to 1 second just for the 
browser/submit/return latency. But it ended up being not an issue. Users 
adapt, especially if you take advantage of what web apps can do. For 
example, use linking so users can go from a page of info/form entry to 
multiple ones to either lookup reference info or fill out data needed 
beforehand. Users appreciate slower single-click functionality versus an 
extremely responsive UI that requires multiple clicks to get into 
different areas and back.

In response to

Responses

pgsql-novice by date

Next:From: operationsengineer1Date: 2005-11-16 17:25:02
Subject: Re: createdb Question
Previous:From: Emiliano AmilcarelliDate: 2005-11-16 14:09:09
Subject: plpython integer types

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group