Re: What is your favorite front end for user interaction to postgresql databases?

On 09.05.2006, at 0:33 Uhr, Karen Hill wrote:

> What is your favorite front end for end users to interact with your
> postgresql db?  Is it java, .net, web apache + php, MS-Access, ruby on
> rails?  Why is it your favorite?  Which would you recommend for end
> users on multiple OSes?

You mean what technology to use to build business logic?

<advertisement>

It just depends on your needs. I prefer to use Apple WebObjects for
building web frontends to the db.

Why? Because it is extremely powerful, free if you are able to
develop on Mac OS X (it comes with the developer tools) and even if
you have to buy a couple of Powerbooks and Xserves it may be cheaper
then only the software license for one of the other big Java
application server technologies. You can deploy it to every Java
plattform because it's just a Java application, but it's build on and
for Mac OS X. It completely frees you from thinking in tables, joins,
selects and other sql stuff, well, at least nearly completely. I can
switch my whole application including a couple of hundred MB database
content in half a day (mostly the time to transfer the data) - I have
done this two months ago from another dbms to PostgreSQL.

It's just as "cool" as Ruby on Rails right now, not as fat and slow
in development as most J2EE servers, you can deploy everywhere, I can
develop on Mac OS X (yes, that's a reason for me, because it speeds
up my work by a good percentage), it is extremely fast for
development once you have the concepts and a good set of your own
components in stock which you are used to. It's pure Java, so I can
easily include third party tools like Lucene or others. It does one
connection per application instance which keeps concurrent db tasks
low. Also it has more than one working approach for multi language /
internationalized applications.

And, most important, it has a tool, which enables me to do things
alone in days, other teams do in weeks with other J2EE tools:
DirectToWeb - a rule and template driven dev plattform. You write the
db schema, lots of "rules" how list, inspect, edit and search pages
should look like and some basic html for wrappers and you can create
an administration application faster as with everything I've seen so
far. Including Ruby on Rails, PHP and other Java tools. But, to make
this clear: the starting point to use it is VERY high. I had  a
couple of years doing WebObjects development when I started using D2W
and it was good to have this background.

Also you can build WebServices, rich Java client apps, can use Ajax
for rich web applications and I have a tool that proved it's
scalability, reliability and ease of use in a real high volume
environment: the iTunes Music Store.

For more information, send me an email and/or go to <http://
www.apple.com/webobjects>. (I hope the url is correct, I'm not online
right now - sitting in the train to work .... ;-))

Ah, and if you download it for testing: go to one of the WO mailing
lists and ask for some good tips for starters. It will help.

</advertisement>

> Also, what do you think of having the database management system do
> all
> work (business logic etc) with the front end as a user interface vs.
> having N-tier with an application server handling business logic, and
> the db just accepting data.

I prefer the second approach because it frees me from one specific
database. I can use Oracle, PostgreSQL, MySQL, FrontBase, OpenBase,
Sybase, MSSQL without changing one line of code (if I have avoided
using custom SQL, which I mostly do) by just switching one framework.
Okay, right, there are always some problems you have to solve, but
they are nothing compared to what a PHP developer has to do to use
different dbms as the one he develops on.

> This comes from having to re-invent the wheel every time a
> new user app needs to  be created.

You do something wrong if you don't build libraries of your basic and
generic work over the time. This has nothing to do with the tool you
use or the underlying dbms - it's just bad coding style if you have
to re-invent the wheel for every app.

For me and our customers it's more important to be able to switch the
dbms than the application server.

But, as with everything: YMMV.

Ah, and for curiosity I'm just evaluating Ruby on Rails: it has
interesting ideas and places itself somewhere between the fat J2EE
app servers and the scripting languages PHP and Perl. It is more
closely placed to WebObjects then I have thought on the first look,
but is a bit easier to learn and not the big 800 pound gorilla of web
development, with hooks, tool, templates, ideas and concepts for
nearly every case.

But in my opinion it lacks a couple of things, two of the most
important for me are complete abstraction from the db (you may reach
this with easy schemas and generic sql but not enough) and a working
internationalization approach. It is lightweight and it would be
interesting to build an application with it. Perhaps, if I have
something with a smaller db schema (under 30 tables) I will try it.

cug