Thread: Big Picture
Josh, Thank you for your informative response. I think I see what I need to do as far as building a workable data model in PostgreSQL. Luckily I'm not restricted to using MS Access. I looked at your suggestion of zope. This looks like it could work for me. My only concern about learning zope is that I'm not convinced that it's database connection for postgreSQL is workable. It's sourceforge web page is not very informative. I have also done some searches for zope in the PostgreSQL newsgroups and have found no real information. I have found some info in zope newsgroups about working with postgresql. I'm a physicist that has be thrown into doing computer stuff at a small company. I'm not afraid of a large learning curve I just don't have time to go up the wrong one. So my real question is: What is the best way to make a generic front to a PostgreSQL database? Any suggestions on what to look into whould be of great help. Brad Paul
Brad, > So my real question is: > What is the best way to make a generic front to a PostgreSQL > database? > > Any suggestions on what to look into whould be of great help. I can't help you further with Zope ... I haven't used it, I've just heard a lot of good things about it. Don't forget to check out PGAccess. If your interface needs are simple, PGAccess may fulfill them. You'd want to learn Tcl, but that is no more difficult than VB. http://www.pgaccess.org/ ... the other advantage to PGAccess is I can guarentee that you will get a lot of support from the PGAccess user/developer community. Also, OpenOffice.org can be used for very simple interfaces as well ... its database tools are not up to the level of MS Access, but good enough for simple forms and reports. However, OpenOffice.org currently uses ODBC or JDBC to access Postgres, so you may be facing some of the same problems you hit with MS Access. That will change when the native drive is completed, but until then ... HEY, LIST: Anybody else have a suggestion? Anybody? Bueller? -Josh Berkus
On Tuesday, October 15, 2002, at 08:48 AM, Brad Paul wrote: > So my real question is: > What is the best way to make a generic front to a PostgreSQL database? Java would get my vote. A simple applet would do the trick and be accessible over a network. You could get more involved with fatter clients or servlet/jsp if that's what's called for. Erik -- Erik Price (zombies roam) email: erikprice@mac.com jabber: erikprice@jabber.org
Zope gets my vote. ----- Original Message ----- From: "Erik Price" <erikprice@mac.com> To: "Brad Paul" <bpaul@carolina.rr.com> Cc: "Josh Berkus" <josh@agliodbs.com>; <pgsql-novice@postgresql.org> Sent: Sunday, October 20, 2002 10:22 PM Subject: Re: [NOVICE] Big Picture > > On Tuesday, October 15, 2002, at 08:48 AM, Brad Paul wrote: > > > So my real question is: > > What is the best way to make a generic front to a PostgreSQL database? > > Java would get my vote. A simple applet would do the trick and be > accessible over a network. You could get more involved with fatter > clients or servlet/jsp if that's what's called for. > > > Erik > > > > > > -- > Erik Price (zombies roam) > > email: erikprice@mac.com > jabber: erikprice@jabber.org > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
On Monday, October 21, 2002, at 07:52 , Erik Price wrote: > > On Tuesday, October 15, 2002, at 08:48 AM, Brad Paul wrote: > >> So my real question is: >> What is the best way to make a generic front to a PostgreSQL database? > > Java would get my vote. A simple applet would do the trick and > be accessible over a network. You could get more involved with > fatter clients or servlet/jsp if that's what's called for. > > > Erik Or, if one were looking for childishly (in programming terms) easy, instant/simultaneous web gratification, try putting as much of your application logic into SQL, use Python CGI scripting, and use a web browser interface. So simple. - Joel
On 22 Oct 2002 at 12:38, Joel Rodrigues wrote: > On Monday, October 21, 2002, at 07:52 , Erik Price wrote: > > On Tuesday, October 15, 2002, at 08:48 AM, Brad Paul wrote: > >> So my real question is: > >> What is the best way to make a generic front to a PostgreSQL database? > > > > Java would get my vote. A simple applet would do the trick and > > be accessible over a network. You could get more involved with > > fatter clients or servlet/jsp if that's what's called for. > > Or, if one were looking for childishly (in programming terms) > easy, instant/simultaneous web gratification, try putting as > much of your application logic into SQL, Yes! > use Python CGI > scripting, and use a web browser interface. So simple. I strongly agree with the web frontend, it will make your app very client independent. Another way to do this is PHP.
On Tuesday, October 22, 2002, at 03:08 AM, Joel Rodrigues wrote: > Or, if one were looking for childishly (in programming terms) easy, > instant/simultaneous web gratification, try putting as much of your > application logic into SQL, use Python CGI scripting, and use a web > browser interface. So simple. Is "putting as much of your application logic into SQL" the preferred way to develop DB-driven applications? I ask this because the only database I've used is MySQL, which I enjoyed learning about and using but required me to implement a lot of the DB logic in my application code. (It was a PHP app.) That's why I want to try PostgreSQL, to get more experience with writing logic into the database itself. But I was curious if there are any resources that discuss why this methodology is preferrable if indeed it is. Thanks, Erik PS: I agree that Python is a great language! -- Erik Price (zombies roam) email: erikprice@mac.com jabber: erikprice@jabber.org
On 22 Oct 2002 at 5:51, Erik Price wrote: <snip> > Is "putting as much of your application logic into SQL" the preferred > way to develop DB-driven applications? <snip> What exactly do you mean with a "DB-driven" app? About the logic, my two cents... There are different views towards this nowadays. I guess most common is the advice to not put your business logic in the frontend. But where? You can put it in the db itself or put it in another layer. This is commonly known as the multi-tier model, you should be able to Google a lot about it. Personally I prefer the approach with as much logic as possible in the database or at least on the server, and a client that is as thin as possible. Maybe it's because I've worked with a db without any constraints etc (lots of .dbf files) which forced me to write a huge app. I think whether you would want a (thin) client-server or a multi-tier model would depend on the need to change your database. If your business logic is in the db and your company would change from postgresql to oracle (or whatever), you have a big problem. With logic in the middle layer that problem would be a lot smaller. With this in mind, also think about using PostgreSQL and PHP with adodb to "translate" your db-specific commands. I haven't used adodb much, but last time I looked, changing from one DBMS involved only a few changes in your PHP code.
Date sent: Tue, 22 Oct 2002 05:51:42 -0400 Subject: Re: [NOVICE] Big Picture From: Erik Price <erikprice@mac.com> To: pgsql-novice@postgresql.org On my cursory reading of Fabien Pascal on dbdebunk.com (which is both refreshing and entertaining and reccommended), he seems to emphasise the need to separate the application from the application's data requirements. Get the data model right and then look hard at how the application might best be implemented. Many rdbms' have a layer (in pg, rules, triggers, plsql etc) which have the potential to support an applications functional requirements, and rdbms' have traditionally wrestled with the eternal problems of concurrency and consistency and are therefore well suited to handle these issues. I'm not sure sql is the place to handle application logic as a rule though. I would tend to put as much control as possible within the database, but no more. The old fashioned idea of three tier applications, database, logic and presentation has much to commend it as a guide. Using each layer as intended will maximise the utility and flexibility of the entire application. All easier said than done, of course and it will always come down to the developer's judgement. Just mt opinion of course Cheers Paul Butler > > On Tuesday, October 22, 2002, at 03:08 AM, Joel Rodrigues wrote: > > > Or, if one were looking for childishly (in programming terms) easy, > > instant/simultaneous web gratification, try putting as much of your > > application logic into SQL, use Python CGI scripting, and use a web > > browser interface. So simple. > > Is "putting as much of your application logic into SQL" the preferred > way to develop DB-driven applications? I ask this because the only > database I've used is MySQL, which I enjoyed learning about and using > but required me to implement a lot of the DB logic in my application > code. (It was a PHP app.) That's why I want to try PostgreSQL, to get > more experience with writing logic into the database itself. But I was > curious if there are any resources that discuss why this methodology is > preferrable if indeed it is. > > Thanks, > > Erik > > PS: I agree that Python is a great language! > > > > > > -- > Erik Price (zombies roam) > > email: erikprice@mac.com > jabber: erikprice@jabber.org > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly
Erik, > Is "putting as much of your application logic into SQL" the preferred > way to develop DB-driven applications? I ask this because the only > database I've used is MySQL, which I enjoyed learning about and using > but required me to implement a lot of the DB logic in my application > code. (It was a PHP app.) That's why I want to try PostgreSQL, to > get more experience with writing logic into the database itself. But > I was curious if there are any resources that discuss why this > methodology is preferrable if indeed it is. Application design: 1-tier application (example: MS Access) Data, interface, and business logic in one layer. 2-tier applications A. MySQL/PHP Interface & Business Logic -- PHP Data -- MySQL B. PostgreSQL/PHP Interface --- PHP Data & Business Logic -- PostgreSQL 3-tier applications (example: Java/CORBA distributed app) Interface: Java/Swing Business Logic: Java EJB Data: PostgreSQL N-tier applications are like the 3-tier, only they keep adding object-oriented layers in the Business Logic portion. 3-tier, or N-tier, applications, are superior programming because they offer abstraction and encapsulation of business logic, which smaller models cannot accomodate. Also, 3-to-N-tier applications are far better at handling data sources and interfaces distributed across several machines or even several networks. However, the more tiers you add, the higher the initial programming time and development cost of the application. Frequently, the n-tier approach is simply overkill for the client's business needs and budget. Of the two 2-tier models, then, I argue strongly that the PostgreSQL/PHP model, with the business logic in the database, is superior, for the following reasons: 1. Language: PostgreSQL functions can make use of SQL, PL/pgSQL, Perl, and C, using each language for what it is best at. Particularly, SQL and PL/pgSQL have the advantage of performing set operations far faster than procedural or OO programming languages -- and many business rules require set operations. 2. Data consistency: It is simply easier to manage perfect data normalization from the database end of things, where triggers and rules can be expected to apply universally, than from interface-level code, where unanticipated exceptions in the code can turn into inconsistent data. Particularly with browser-based interfaces, client sessions may be interrupted at any time, so it's hard to depend on interface code for consistency. 3. Maintainence: Close integration of interface display code with business logic (the MySQL/PHP model) is high-maintainence because often changes to the interface display cause bugs in the business logic code. 4. Security: If your entire business logic is in PHP, there is no way to secure or limit access to the database from an attacker who gains control of the web server. If the PHP code is constrained by database-side business logic, however, it is much easier to limit the damage even a priveleged attacker can do through database security. 5. Portability: If your interface contains little or no business logic, then it is far faster to replicate it on a new platform because there is simply less code on the interface side of things. For example, if you had a PHP interface which you wanted to replicate using C on the Palm, it would be considerably less work to do so if all you need worry about were data layout and forms, rather than security, normalization, and concurrent edits as well. Persuasive? -Josh Berkus
Hi, This question has come up in so many projects I have worked on. Here is the overly-simplified rule I offer at the start of the decision-making process: If a violation of the "rule" would result in nonsense data, the rule should be in the db, therefore no rogue application code can ever violate the ruls. If a violation of the "rule" would not result in nonsense data, simply a business desire that is not followed, then I recommend to put the rule in the middle layer. Example: Business decides not to sell guns online on Washington's birthday. This rule goes outside the db. If a gun is sold in violation of the rule, the order still makes sense, the customer got their product and the company got paid. Business rule says each order line item must be associated to one and only one order number. This rule goes in the db, obviously an order line without an order is nonsense. Admittedly this is an oversimplification, but it provides me with a very useful rule-of-thumb for framing the debate. Comments? Ken -----Original Message----- From: pgsql-novice-owner@postgresql.org [mailto:pgsql-novice-owner@postgresql.org]On Behalf Of Erik Price Sent: Tuesday, October 22, 2002 2:52 AM To: pgsql-novice@postgresql.org Subject: Re: [NOVICE] Big Picture On Tuesday, October 22, 2002, at 03:08 AM, Joel Rodrigues wrote: > Or, if one were looking for childishly (in programming terms) easy, > instant/simultaneous web gratification, try putting as much of your > application logic into SQL, use Python CGI scripting, and use a web > browser interface. So simple. Is "putting as much of your application logic into SQL" the preferred way to develop DB-driven applications? I ask this because the only database I've used is MySQL, which I enjoyed learning about and using but required me to implement a lot of the DB logic in my application code. (It was a PHP app.) That's why I want to try PostgreSQL, to get more experience with writing logic into the database itself. But I was curious if there are any resources that discuss why this methodology is preferrable if indeed it is. Thanks, Erik PS: I agree that Python is a great language! -- Erik Price (zombies roam) email: erikprice@mac.com jabber: erikprice@jabber.org ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
On Tue, 22 Oct 2002 05:51:42 -0400 Erik Price wrote:
> Is "putting as much of your application logic into SQL" the preferred
> way to develop DB-driven applications?
It's one way, argued strongly by Philip Greenspun:
http://philip.greenspun.com/panda/databases-interfacing
Regards,
Giles
The business model that we use is based on N-tier architecture, where you have the following levels: User Interface - Buttons on screen etc. Application Logic - What site navigation etc. Business Logic - core logic. E.g. running a report Persistence - storing data Now, persistence really has to be in the database. Traditionally, both business logic and application logic are mixed together and carried out in the application layer (php). However, we prefer to separate business logic and application logic, and put business logic in the database. This cannot be done with MySQL of course, but is possible with PostGreSQL. Basically, you create an API where the application layer can only access the database via the defined views and stored procedures (functions in Postgres). Does this make sense? ----- Original Message ----- From: "ken" <kenzo@kennethambrose.com> To: "Erik Price" <erikprice@mac.com>; <pgsql-novice@postgresql.org> Sent: Wednesday, October 23, 2002 6:58 AM Subject: Re: [NOVICE] Big Picture > Hi, > This question has come up in so many projects I have worked on. Here is the > overly-simplified rule I offer at the start of the decision-making process: > > If a violation of the "rule" would result in nonsense data, the rule should > be in the db, therefore no rogue application code can ever violate the ruls. > > If a violation of the "rule" would not result in nonsense data, simply a > business desire that is not followed, then I recommend to put the rule in > the middle layer. > > Example: > > Business decides not to sell guns online on Washington's birthday. This rule > goes outside the db. If a gun is sold in violation of the rule, the order > still makes sense, the customer got their product and the company got paid. > > Business rule says each order line item must be associated to one and only > one order number. > This rule goes in the db, obviously an order line without an order is > nonsense. > > Admittedly this is an oversimplification, but it provides me with a very > useful rule-of-thumb for framing the debate. > > Comments? > > Ken > > -----Original Message----- > From: pgsql-novice-owner@postgresql.org > [mailto:pgsql-novice-owner@postgresql.org]On Behalf Of Erik Price > Sent: Tuesday, October 22, 2002 2:52 AM > To: pgsql-novice@postgresql.org > Subject: Re: [NOVICE] Big Picture > > > > On Tuesday, October 22, 2002, at 03:08 AM, Joel Rodrigues wrote: > > > Or, if one were looking for childishly (in programming terms) easy, > > instant/simultaneous web gratification, try putting as much of your > > application logic into SQL, use Python CGI scripting, and use a web > > browser interface. So simple. > > Is "putting as much of your application logic into SQL" the preferred > way to develop DB-driven applications? I ask this because the only > database I've used is MySQL, which I enjoyed learning about and using > but required me to implement a lot of the DB logic in my application > code. (It was a PHP app.) That's why I want to try PostgreSQL, to get > more experience with writing logic into the database itself. But I was > curious if there are any resources that discuss why this methodology is > preferrable if indeed it is. > > Thanks, > > Erik > > PS: I agree that Python is a great language! > > > > > > -- > Erik Price (zombies roam) > > email: erikprice@mac.com > jabber: erikprice@jabber.org > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > >
On Tuesday, October 22, 2002, at 01:03 PM, Josh Berkus wrote: > Persuasive? Absolutely. It has pointed out the biggest hole in my programming knowledge: incorporating application logic into the database. MySQL + PHP made sense to me, because I used PHP to do all of my decision-making and MySQL as a place to temporarily or permanently store data. It worked great. But it does have the vulnerabilities that you mention in your post. I'd like to learn more about writing applications that don't have those kinds of vulnerabilities (even if MySQL + PHP does the job just fine, it's for the sake of learning). Does anyone recommend a book or resource on putting more business/app logic into the DB? Thanks, Erik -- Erik Price (zombies roam) email: erikprice@mac.com jabber: erikprice@jabber.org
On Tuesday, October 22, 2002, at 06:08 AM, Jules Alberts wrote: > What exactly do you mean with a "DB-driven" app? Oh, sorry. I meant an application that uses a RDBMS back end for persistence. Just about any web browser-based application is a good example of what I meant. As opposed to say, a desktop app that might store some configuration and preferences info in a few text files. Erik -- Erik Price (zombies roam) email: erikprice@mac.com jabber: erikprice@jabber.org
Hi, I think the definitions you describe below for application vs. business logic are maybe not quite rigourous enough for me to try and use in the workplace. But I am a database guy, I confess I like the idea of rules in the db. However there are always trade-offs. My general thinking is that one fundamental concept of RDBMS is data _independance_ from applications (if I understand Dr. Codd correctly). This faciliates the _same_ data to be used effectively and safely by many different applications over the lifetime of the enterprise. So if additional code in the database reduces the effectiveness with which data can be shared among different applications in the enterprise, at that point I would advocate for that code to be somewhere else (assuming that code doesn't risk "nonsense" data). Also certain rules will tend to have high liklihood of change over the lifetime of an enterprise, and certain rules are extremely unlikely to ever change. That is another criteria I use for the decision. I do not like the idea of having to change the most critical code in the enterprise any more than is absolutely neccesary. Ask the business people, domain experts, or stake-holders- "will this rule ever change?" and "what is the likelihood that the rule will ever change?" The answers to those questions would provide clues where the code should live. If it is likely to change, I would think it should not be in the DB... Ken Ambrose -----Original Message----- From: pgsql-novice-owner@postgresql.org [mailto:pgsql-novice-owner@postgresql.org]On Behalf Of Mark Wilson Sent: Tuesday, October 22, 2002 2:44 PM To: pgsql-novice@postgresql.org Subject: Re: [NOVICE] Big Picture The business model that we use is based on N-tier architecture, where you have the following levels: User Interface - Buttons on screen etc. Application Logic - What site navigation etc. Business Logic - core logic. E.g. running a report Persistence - storing data Now, persistence really has to be in the database. Traditionally, both business logic and application logic are mixed together and carried out in the application layer (php). However, we prefer to separate business logic and application logic, and put business logic in the database. This cannot be done with MySQL of course, but is possible with PostGreSQL. Basically, you create an API where the application layer can only access the database via the defined views and stored procedures (functions in Postgres). Does this make sense? ----- Original Message ----- From: "ken" <kenzo@kennethambrose.com> To: "Erik Price" <erikprice@mac.com>; <pgsql-novice@postgresql.org> Sent: Wednesday, October 23, 2002 6:58 AM Subject: Re: [NOVICE] Big Picture > Hi, > This question has come up in so many projects I have worked on. Here is the > overly-simplified rule I offer at the start of the decision-making process: > > If a violation of the "rule" would result in nonsense data, the rule should > be in the db, therefore no rogue application code can ever violate the ruls. > > If a violation of the "rule" would not result in nonsense data, simply a > business desire that is not followed, then I recommend to put the rule in > the middle layer. > > Example: > > Business decides not to sell guns online on Washington's birthday. This rule > goes outside the db. If a gun is sold in violation of the rule, the order > still makes sense, the customer got their product and the company got paid. > > Business rule says each order line item must be associated to one and only > one order number. > This rule goes in the db, obviously an order line without an order is > nonsense. > > Admittedly this is an oversimplification, but it provides me with a very > useful rule-of-thumb for framing the debate. > > Comments? > > Ken > > -----Original Message----- > From: pgsql-novice-owner@postgresql.org > [mailto:pgsql-novice-owner@postgresql.org]On Behalf Of Erik Price > Sent: Tuesday, October 22, 2002 2:52 AM > To: pgsql-novice@postgresql.org > Subject: Re: [NOVICE] Big Picture > > > > On Tuesday, October 22, 2002, at 03:08 AM, Joel Rodrigues wrote: > > > Or, if one were looking for childishly (in programming terms) easy, > > instant/simultaneous web gratification, try putting as much of your > > application logic into SQL, use Python CGI scripting, and use a web > > browser interface. So simple. > > Is "putting as much of your application logic into SQL" the preferred > way to develop DB-driven applications? I ask this because the only > database I've used is MySQL, which I enjoyed learning about and using > but required me to implement a lot of the DB logic in my application > code. (It was a PHP app.) That's why I want to try PostgreSQL, to get > more experience with writing logic into the database itself. But I was > curious if there are any resources that discuss why this methodology is > preferrable if indeed it is. > > Thanks, > > Erik > > PS: I agree that Python is a great language! > > > > > > -- > Erik Price (zombies roam) > > email: erikprice@mac.com > jabber: erikprice@jabber.org > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > > ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
> Hi, > I think the definitions you describe below for application vs. business > logic are maybe not quite rigourous enough for me to try and use in the > workplace. But I am a database guy, I confess I like the idea of rules in > the db. However there are always trade-offs. > > My general thinking is that one fundamental concept of RDBMS is data > _independance_ from applications (if I understand Dr. Codd correctly). This > faciliates the _same_ data to be used effectively and safely by many > different applications over the lifetime of the enterprise. So if > additional code in the database reduces the effectiveness with which data > can be shared among different applications in the enterprise, at that point > I would advocate for that code to be somewhere else (assuming that code > doesn't risk "nonsense" data). I'm not really sure what your're saying here. But on reason for putting business logic rules in the database is that it ensures that all applications do the same thing. For example, suppose you have two entities, and wish to assign them together. This may entail putting entries in assignment tables, setting fields to initialise the start of the relationship etc. Putting this business logic in the database and only providing an assign_a_to_b function (rather than direct insert access on the tables) ensures that all applications correctly assign the two things. It's usually more efficient too if multiple tables are affected. > Also certain rules will tend to have high liklihood of change over the > lifetime of an enterprise, and certain rules are extremely unlikely to ever > change. That is another criteria I use for the decision. I do not like the > idea of having to change the most critical code in the enterprise any more > than is absolutely neccesary. Ask the business people, domain experts, or > stake-holders- "will this rule ever change?" and "what is the likelihood > that the rule will ever change?" The answers to those questions would > provide clues where the code should live. If it is likely to change, I would > think it should not be in the DB... Actually, I would stored these 'configurable' rules in the database, but rather than hardcode the whole rule into a function, stored the 'variable' components in a table. But of course that presumes that you know what the future change will be.. Mark
Ken,
> > My general thinking is that one fundamental concept of RDBMS is
> data
> > _independance_ from applications (if I understand Dr. Codd
> correctly).
> This
> > faciliates the _same_ data to be used effectively and safely by
> many
> > different applications over the lifetime of the enterprise. So if
> > additional code in the database reduces the effectiveness with
> which data
> > can be shared among different applications in the enterprise, at
> that
> point
> > I would advocate for that code to be somewhere else (assuming that
> code
> > doesn't risk "nonsense" data).
But it does risk "nonsense" data. Look,in an ideal application, you
would have:
layer 1: SQL-DDL: tables, data repository
layer 2: Views, Triggers, Rules and Constraints: data integrity rules
and data abstraction
layer 3: Perl, Java, CORBA, whatever: data access and data security
rules
layer 4: Perl, Java, CORBA, whatever: business rules and logic
layer 5: Perl, Java, CORBA, whatever: application logic and flow
control and user rights
layer 6: HTTP + Perl/PHP or Java or QT or whatever: User interface
components.
Which is real great if you're working with a $250,000 budget. However,
most of my applications run about $9,000 and look more like:
layer 1: SQL-DDL: Data repository. tables
layer 2: Views, Triggers, Constraints, PL/pgSQL procedures: data
security, business rules & logic, data integrity rules
layer 3: HTTP + PHP: user interface components, flow control, user
rights.
For the above 3-layer "simple" application, putting the business rules
in PostgreSQL procedures, triggers, and rules makes a *lot* more sense
than putting them in the PHP. Yes?
-Josh Berkus