Subject Re: [firebird-support] Re: Company Intranet on Firebird?
Author Werner F. Bruhin
On 24/09/2010 21:30, Doug Chamberlin wrote:
> On 9/23/2010 4:29 PM, nigma2020 wrote:
>> Now I'm considering whether or not I want to delve very deep into database development, or whether MS Access would suffice. I have a few Access 2003 programs that I worked on with an uncle years back, but I definitely would like to use something with a bit more polish.
>>
>> I understand HTML, but as a standalone application, I'm not really understanding how much work will go into a Firebird GUI (for clients) I picked up a book on MySQL, figuring it would be similar, but They all seem to be based on the integration with PHP. Should I take this as a sign that developing full-fledged standalone apps with firebird is a whole 'nother ballgame?
> You are mixing a number of different things in your thinking.
>
> First, you have database engines. These manage storage of data and need
> some sort of front end to be useful. These include Oracle, MS SQL
> Server, Firebird, PostgreSQL, mySQL, MS Jet (recently renamed and used
> by MS Access).
>
> Some of these are open source, some are proprietary. Some run on many
> platforms, some just one. Pick one with as much flexibility as you can.
>
> Second, you have application architecture. Web apps need a web server
> (e.g. Apache, MS IIS) and a server-based engine to run the app (e.g.
> PHP, Cold Fusion, custom app server, etc). Some of these are open
> source, some proprietary. Some have large community support, some less.
> All require programming at some level to create your application. All
> require some programming attention to ensure the app will run OK on the
> web browsers you are targeting. (This is getting easier but is far from
> ideal.)
>
> The client for web apps is a browser (MS Internet Explorer, Firefox,
> Opera, Safari). Some are open source, some not.
>
> Third, are client-server apps. These are programs that run on the client
> machine and access data direct from the database engine (no web server,
> no app server). Delphi is the tool of choice for these for running on
> Windows clients. MS Access can also create this part using its GUI tools
> and that makes it a hybrid product. The relative complexity of
> programming these on other platforms is part of what has pushed people
> toward web apps.
>
> Finally, there are n-tier apps. These are like either web apps or
> client-server apps but they are distinguished by the presence of a
> middle server that isolates the client from the database storage engine.
> Sometimes this is an app server that directly talks to the client
> program. This can also be a web-server based REST interface. Lots of
> variation here.
>
> One of the best attributes of n-tier apps is that each piece (client,
> app server, storage engine) can be chosen relatively independently of
> the others.
>
> IMHO, the best bang for your buck is client-server. It only loses out
> when you factor in widely different client platform support (Windows,
> Linux, and Mac are all required) or deployment across wide areas where a
> single LAN is not the normal operating environment.
>
I would stay away from Access, haven't used it for years but I recall a
project in a company I worked where we run into a wall pretty far down
in the development due to its poor support for multi users.

I use Firebird for my shareware for a few years now and I never had any
database related problems. I have done it using Python/wxPython but if
I would start over again I would probably use Dabo (which is a framework
on top of wxPython, especially for database applications) -
http://dabodev.com/documentation , check out some of the screen casts on
this page. Documentation is still a bit lacking but more then
compensated by the very good support via the list
(http://leafe.com/mailman/listinfo/dabo-users). Some time ago they
started working on a web application with a "twist" see here -
http://j.mp/830AMm , some time ago I started playing with this but run
out of time - at least for the moment.

Werner