Jonathan,
This is exactly how my company has built a very robust ERP application. See www.openmfg.com.
All the ERP business logic is in pl/pgsql (20,000+ lines, very high fiber content). The GUI is the Qt framework for C++, which gives us a client in Linux, Windows, Mac OS X, and even wireless (embedded Linux) - with one source tree to maintain. Bringing up various web views into the system (using python, PHP, etc) is a snap as well.
Performance is outstanding, as you would expect. We have commodity Intel servers running Linux typically serving dozens of concurrent users of a very transaction-intensive system.
Cheers, Ned Lilly
Jonathan M. Gardner wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Consider this. Most (well-written) applications are written in three layers. The data abstraction layer provides a clean interface to the underlying data so other people don't have to write SQL statements. The GUI layer handles all the GUI events and translates them into function calls or attribute modifications. Then the layer in between coordinates the two and often handles more complicated business rules.
A few nights ago, I implemented some of my application logic in PostgreSQL via PL/PythonU. I was simply amazed at what I was able to do. My question becomes: Why not get rid of the middle layer and move it into the databse entirely?
The GUI layer would then merely connect to the database and just connect user actions to actions in the database, and then suck all the data it needs disrectly from the databsae with a simple interface. Think SOAP, but where the SOAP server is on the PostgreSQL, and without all the nasty overhead.
The layer on top of the database would provide proxy objects that the GUI could access and modify. These accesses and modifications are translated into accesses and modifications of the objects underneath. All the business logic is stored in the database server.
Thoughts? Comments? Hasn't Oracle done something like this?
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
