Thread: Application Development with PostgreSQL
I�m really a newbie when it comes to application development, I used to develop website through PHP and now I�m undergoing training for application development� I hope you can answer some of my questions. Me and my colleagues would like to develop help fix one of the application in the company. This application will be shared throughout the company network. One of my colleagues suggested the use of PostgreSQL for some data and use it together with Delphi or Visual Basic. In general there any advantage in using Delphi / VB than using ordinary PHP�particularly with speed and reliability issues? For those who will take time to answer this simple question�thank you very much. :-) Regards, Joanne Formoso __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Joanne, > Im really a newbie when it comes to application > development, I used to develop website through PHP and > now Im undergoing training for application > development I hope you can answer some of my > questions. Me and my colleagues would like to develop > help fix one of the application in the company. This > application will be shared throughout the company > network. One of my colleagues suggested the use of > PostgreSQL for some data and use it together with > Delphi or Visual Basic. In general there any > advantage in using Delphi / VB than using ordinary > PHP particularly with speed and reliability issues? I can give you a very simple answer: No. The advantage of using Delphi or VB for your interface are the advantages that come with a client-side application instead of a web app: 1) Interactive & immediate response to user input (no screen reloads). 2) Fine-grained formatting options and printer-friendly reporting. 3) Two-way session control for user security. The disadvantages are: 1) Platform dependence (e.g. VB runs only on Windows and Delphi doesn't do OSX). 2) Plaform version issues and corruption of program binaries by viruses and disk corruption on the desktop; 3) Rollout issues with installing each interface bug fix on each user desktop; 4) Secure communications protocol issues with communication btw. the desktop clients and the server; 5) Speed issues with poorly configured or "sick" desktop machines; 6) Vastly more cumbersome external access for work-from-home users. My company used to develop applications using VB clients. Now we pretty much exclusively develop intranet-based applications (usually PHP + PostgreSQL); they are cheaper, easier, and faster. -- Josh Berkus Aglio Database Solutions San Francisco
On Sun, 2003-05-04 at 13:28, Josh Berkus wrote: [snip] > The advantage of using Delphi or VB for your interface are the advantages that > come with a client-side application instead of a web app: > 1) Interactive & immediate response to user input (no screen reloads). > 2) Fine-grained formatting options and printer-friendly reporting. > 3) Two-way session control for user security. These are important points. > The disadvantages are: > 1) Platform dependence (e.g. VB runs only on Windows and Delphi doesn't do > OSX). > 2) Plaform version issues and corruption of program binaries by viruses and > disk corruption on the desktop; And these are also important issues! Using Python/Perl/Java (am I missing one?) would mitigate platform dependence. > 3) Rollout issues with installing each interface bug fix on each user desktop; > 4) Secure communications protocol issues with communication btw. the desktop > clients and the server; > 5) Speed issues with poorly configured or "sick" desktop machines; Wouldn't these (especially 3 & 5) be solved by Terminal Services. #3 would also be partly (or totally, with some care) solved by having the app residing on a network drive. > 6) Vastly more cumbersome external access for work-from-home users. How so? I'd think that "traditional" C/S would be faster, because certain "objects" can be intelligently cached by the client, on start-up, for example. Don't look-up lists have to be sent across the wire every time on web pages? -- +-----------------------------------------------------------+ | Ron Johnson, Jr. Home: ron.l.johnson@cox.net | | Jefferson, LA USA http://members.cox.net/ron.l.johnson | | | | An ad currently being run by the NEA (the US's biggest | | public school TEACHERS UNION) asks a teenager if he can | | find sodium and *chloride* in the periodic table of the | | elements. | | And they wonder why people think public schools suck... | +-----------------------------------------------------------+
If you have some patience, I'm developing a pgsql protocol class for use with REALbasic, which should be compatible with Mac Classic, OS X, and Win98 and up. (You can find more info about the development environment for which I am making this at www.realbasic.com. With the 'pro' license, you can already have a pgsql plugin that will perhaps perform acceptably and with some caveats for up to 6000 records--on my system. I'm going for the real speed however.) Marc
Ron, > And these are also important issues! > > Using Python/Perl/Java (am I missing one?) would mitigate platform > dependence. Yes. But she was comparing rapid app dev kits, not programming languages; Delphi and VB are fast GUI-builders. > Wouldn't these (especially 3 & 5) be solved by Terminal Services. > #3 would also be partly (or totally, with some care) solved by having > the app residing on a network drive. Yes. But if you're going to do that, why bother with client-side programming? I suppose if your app needs advantages 1 & 2, I guess ... And applying app changes across sessions on a terminal server is still significantly more trouble than applying a change to a web app. With a PHP app, you just save the new file in /wwwroot, and bang! It's applied to all users. > > 6) Vastly more cumbersome external access for work-from-home users. > > How so? I'd think that "traditional" C/S would be faster, because > certain "objects" can be intelligently cached by the client, on > start-up, for example. Don't look-up lists have to be sent across > the wire every time on web pages? If you want home access to a client side app, you have to mess with VPNs and firewalls and/or remote terminal services. Ever try providing support for 150 user with gods know what running on their home machines, along with more viruses than megabytes of ram? (we had a fun conversation when the IT dept at one client got a phone call from a staff member who couldn't figure out how to install Mozilla. Turns out the staffer had an Amiga) For a web app, you just route a path from the web server to the internet. Then tell the user to use a brower. Very easy. From my perspective, the age of the "thin client" is here. -- Josh Berkus Aglio Database Solutions San Francisco
From: Josh Berkus <josh@agliodbs.com>
Organization: Aglio Database Solutions
To: Ron Johnson <ron.l.johnson@cox.net>,
PgSQL Novice ML <pgsql-novice@postgresql.org>
Subject: Re: [NOVICE] Application Development with PostgreSQL
Date sent: Sun, 4 May 2003 20:37:03 -0700
While I do not claim to be an authority on these matters, I would have to agree with
Josh on this one, its almost trivial to set up a decent VPN these days. The question, as
always, is how much time you or your client want to spend on security and ergonomics.
A web app can host the application and provide a repository for any helper applications
that might be needed, (say a grid applet or whatever). The thin client that the browser
offers may not be ideal, but it is exteremely versatile and robust. You just have to weigh
the requirements and choose the right horse for the course.
What ie5/php/postgresql+a reliable network connection offers out of the box is
ridiculously good, and should make it a combination worth considering. (If you want tidy
reporting, grab the pdf library). I'm a big python fan, but building the client side from
scratch, maintaining and distributing it is never simple. As for caching look up lists, if
you gzip things, it shouldn't take any longer than downloading a gif.
The wonderful thing is that the thin client is not just here, it's everywhere. This leaves
the developer one less thing to worry about and allows them to concentrate on
correctness, and finally performance(which is always the straw man of computing
disagreements).
Thats my two bob's worth of opinion.
Cheers
Paul Butler
on,
>
> > And these are also important issues!
> >
> > Using Python/Perl/Java (am I missing one?) would mitigate platform
> > dependence.
>
> Yes. But she was comparing rapid app dev kits, not programming languages;
> Delphi and VB are fast GUI-builders.
>
> > Wouldn't these (especially 3 & 5) be solved by Terminal Services.
> > #3 would also be partly (or totally, with some care) solved by having
> > the app residing on a network drive.
>
> Yes. But if you're going to do that, why bother with client-side
> programming? I suppose if your app needs advantages 1 & 2, I guess ...
>
> And applying app changes across sessions on a terminal server is still
> significantly more trouble than applying a change to a web app. With a PHP
> app, you just save the new file in /wwwroot, and bang! It's applied to all
> users.
>
> > > 6) Vastly more cumbersome external access for work-from-home users.
> >
> > How so? I'd think that "traditional" C/S would be faster, because
> > certain "objects" can be intelligently cached by the client, on
> > start-up, for example. Don't look-up lists have to be sent across
> > the wire every time on web pages?
>
> If you want home access to a client side app, you have to mess with VPNs and
> firewalls and/or remote terminal services. Ever try providing support for
> 150 user with gods know what running on their home machines, along with more
> viruses than megabytes of ram? (we had a fun conversation when the IT dept
> at one client got a phone call from a staff member who couldn't figure out
> how to install Mozilla. Turns out the staffer had an Amiga)
>
> For a web app, you just route a path from the web server to the internet.
> Then tell the user to use a brower. Very easy.
>
> From my perspective, the age of the "thin client" is here.
>
> --
> Josh Berkus
> Aglio Database Solutions
> San Francisco
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
On Sun, 2003-05-04 at 22:37, Josh Berkus wrote: > Ron, > > > And these are also important issues! > > > > Using Python/Perl/Java (am I missing one?) would mitigate platform > > dependence. > > Yes. But she was comparing rapid app dev kits, not programming languages; > Delphi and VB are fast GUI-builders. True. > > Wouldn't these (especially 3 & 5) be solved by Terminal Services. > > #3 would also be partly (or totally, with some care) solved by having > > the app residing on a network drive. > > Yes. But if you're going to do that, why bother with client-side > programming? I suppose if your app needs advantages 1 & 2, I guess ... > > And applying app changes across sessions on a terminal server is still > significantly more trouble than applying a change to a web app. With a PHP > app, you just save the new file in /wwwroot, and bang! It's applied to all > users. #1 & #2 are important many times. While TS might not be perfect, putting an app out on a network drive is also pretty easy. Next time you come in to work, there's your new version. > > > 6) Vastly more cumbersome external access for work-from-home users. > > > > How so? I'd think that "traditional" C/S would be faster, because > > certain "objects" can be intelligently cached by the client, on > > start-up, for example. Don't look-up lists have to be sent across > > the wire every time on web pages? > > If you want home access to a client side app, you have to mess with VPNs and > firewalls and/or remote terminal services. Ever try providing support for > 150 user with gods know what running on their home machines, along with more > viruses than megabytes of ram? (we had a fun conversation when the IT dept > at one client got a phone call from a staff member who couldn't figure out > how to install Mozilla. Turns out the staffer had an Amiga) Heck, I use a VPN every day as a telecommuter. There's gonna be idiot users everywhere, no matter how simple you make it... > For a web app, you just route a path from the web server to the internet. > Then tell the user to use a brower. Very easy. Maybe it's just me, but I'm not a big fan of pumping everything through port 80. (This is where Web Services really scares me.) > From my perspective, the age of the "thin client" is here. It's here alright, but "thin client" doesn't *equate* to web-based interaction. Thank goodness for LAPP (linux, apache, postgresql, php) but it's not the solution to every on-line system. -- +-----------------------------------------------------------+ | Ron Johnson, Jr. Home: ron.l.johnson@cox.net | | Jefferson, LA USA http://members.cox.net/ron.l.johnson | | | | An ad currently being run by the NEA (the US's biggest | | public school TEACHERS UNION) asks a teenager if he can | | find sodium and *chloride* in the periodic table of the | | elements. | | And they wonder why people think public schools suck... | +-----------------------------------------------------------+
Ron, > While TS might not be perfect, putting an app out on a network drive is > also pretty easy. Next time you come in to work, there's your new > version. > Heck, I use a VPN every day as a telecommuter. Sure. I was just pointing out that the logistics of getting 150 home users to install and configure compatible VPN clients on their home PCs is significantly greater that installing browsers, especially as many users will already have compatible browsers. > There's gonna be idiot users everywhere, no matter how simple you make > it... Actually, I wasn't pointing out the idiocy of the user, but the variety of platforms and hardare an IT department has to support once the app is extended to home users. In VPNs favor, it can be made much more secure than SSL can ever be. > Maybe it's just me, but I'm not a big fan of pumping everything > through port 80. (This is where Web Services really scares me.) Beyond the script kiddie issue, what's to worry about? > It's here alright, but "thin client" doesn't *equate* to web-based > interaction. > > Thank goodness for LAPP (linux, apache, postgresql, php) but it's > not the solution to every on-line system. You're absolutely right. My point is merely that unless "advantages 1&2" are very important to your application, "LAPP" is probably the cheapest, fastest (to develop) and more reliable application architectures currently available. I've certainly developed applications where 1&2's importance was overwhelming ... for example, a financial reporting application we wrote 2 years ago in VB6. The app had to fit a lot of data on a small screen, and had to print highly formatted reports running to hundreds of pages. This is not something to which web apps are suited. And there certainly are non-web-based thin client architectures -- I support one of my clients on Citrix, for example. My experience, however, has been that terminal-services based solutions for applications (so, not LTSP) tend to be high-maintainence and expensive (WTS is $150/user, last I checked). -- Josh Berkus Aglio Database Solutions San Francisco
On Mon, 2003-05-05 at 11:13, Josh Berkus wrote: > Ron, [snip] > > Maybe it's just me, but I'm not a big fan of pumping everything > > through port 80. (This is where Web Services really scares me.) > > Beyond the script kiddie issue, what's to worry about? If your app uses a non-standard port, then you can have more control than if everything and the kitchen sink flows through port 80. > > It's here alright, but "thin client" doesn't *equate* to web-based > > interaction. > > > > Thank goodness for LAPP (linux, apache, postgresql, php) but it's > > not the solution to every on-line system. > > You're absolutely right. My point is merely that unless "advantages 1&2" are > very important to your application, "LAPP" is probably the cheapest, fastest > (to develop) and more reliable application architectures currently available. > > I've certainly developed applications where 1&2's importance was overwhelming > ... for example, a financial reporting application we wrote 2 years ago in > VB6. The app had to fit a lot of data on a small screen, and had to print > highly formatted reports running to hundreds of pages. This is not something > to which web apps are suited. What if I need multiple scrolling regions, and the ability to be "mouse free" (for clerks doing heads-down work)? > And there certainly are non-web-based thin client architectures -- I support > one of my clients on Citrix, for example. My experience, however, has been > that terminal-services based solutions for applications (so, not LTSP) tend > to be high-maintainence and expensive (WTS is $150/user, last I checked). High maintenance? Really? -- +-----------------------------------------------------------+ | Ron Johnson, Jr. Home: ron.l.johnson@cox.net | | Jefferson, LA USA http://members.cox.net/ron.l.johnson | | | | An ad currently being run by the NEA (the US's biggest | | public school TEACHERS UNION) asks a teenager if he can | | find sodium and *chloride* in the periodic table of the | | elements. | | And they wonder why people think public schools suck... | +-----------------------------------------------------------+
Josh Berkus <josh@agliodbs.com> writes:
> In VPNs favor, it can be made much more secure than SSL can ever be.
Really? Why is that? VPN seems *less* safe to me, because by default
it opens up all ports to pass through the tunnel. With SSL you know
exactly what ports will be forwarded.
regards, tom lane
On Mon, 2003-05-05 at 18:36, Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> writes: > > In VPNs favor, it can be made much more secure than SSL can ever be. > > Really? Why is that? VPN seems *less* safe to me, because by default > it opens up all ports to pass through the tunnel. With SSL you know > exactly what ports will be forwarded. My company gave me an RSA SecurID token (the size of a small pager), that generates a new six digit random number every 60 seconds. When I want to connect to the corporate VPN server, I type in my PIN number and the SecurID token. The VPN client software then says Security ESP - Triple DES, SHA IKE Diffie-Hellman Group I -- +---------------------------------------------------------------+ | Ron Johnson, Jr. mailto:ron.l.johnson@cox.net | | Jefferson, LA USA http://members.cox.net/ron.l.johnson | | | | The purpose of the military isn't to pay your college tuition | | or give you a little extra income; it's to "kill people and | | break things". Surprisingly, not everyone understands that. | +---------------------------------------------------------------+
Tom, > Really? Why is that? VPN seems *less* safe to me, because by default > it opens up all ports to pass through the tunnel. With SSL you know > exactly what ports will be forwarded. With my clientele, the majority of *directed* attacks against their systems are sociological, rather than cracker attacks. For example: One of my clients thought is was clever to give all of the employees their middle names, oddly capitalized, as passwords. This made it very easy for ex-employees to guess the passwords of current employees, and one of them did ... plus this client frequently failed to cancel the accounts of terminated employees for up to 3 weeks. Another client, an attorney, wrote down his "extranet" username and password on a post-it, and then stuck it to the outside of his laptop, which he took to court. He therefore shared his login information with everyone in the courtroom ... including opposing counsel. In both of those cases, attackers* were able to gain legitimate user names and passwords. If they log in to an HTTP/SSL system, the web server has no way to distinguish between a legitimate user and an attacker with a legitimate password. A VPN-based system imposes an additional barrier to the sociological attacker in the form of requiring them to procure and install specialized VPN software. This barrier can be made additionally impervious by having the IT department issue keys to the remote client machines rather than relying on the VPN software's auto generated keys. However, all of this is a big pain in the keister to administrate, which is why I've only recommended it to one client, and they decided against the expense. (* = when I say "attacker" I'm not talking about someone who wants to crash the web server. My clients are law and accounting firms; what they are worried about is unauthorized users gaining access to information which would compromise their clients. A script kiddie hosing the web server is a *secondary* concern; it's a lot cheaper to re-build a web server than to defend a malpractice suit) -- Josh Berkus Aglio Database Solutions San Francisco