Обсуждение: Wich the best way to control the logic of a web application?

Hi,

Now I'am with some doubts on how to control the logic of a web application?

So... the web application uses PHP, object oriented and PostgresSQL Database. I have developed some procedures and functions in the database but I don't know if it is correct to mix logic in the database and PHP.

What do you think aboout this? Should I mix logic in Database and PHP or should I control the logic only in the PHP?

Best Regards,
André.

On Wed, Aug 19, 2009 at 05:46:17PM +0100, Andre Lopes wrote:
> What do you think aboout this? Should I mix logic in Database and PHP or
> should I control the logic only in the PHP?

As always, it depends!  I tend to put things where ever it's most
convenient, however data integrity and other invariants within your
code will dictate some levels above which you can't place code.  In
your email address example before, this can easily be done in PHP (or
even JavaScript, client side) as the database doesn't care whether it's
getting a valid email address or not--it's just a character string
to the database.  To go to the other extreme, referential integrity
is (almost?) always best done inside the database as it has all the
information needed to do the right thing.

--
  Sam  http://samason.me.uk/

On Aug 19, 2009, at 9:46 AM, Andre Lopes wrote:
> What do you think aboout this? Should I mix logic in Database and
> PHP or should I control the logic only in the PHP?

There are no real hard and fast rules, of course, just rules of
thumb.  Here are some of mine.

First, remember that there is rarely "an application" for a database.
One of the most useful parts of a database is that it provides a
central repository for data across multiple applications.  For now,
the web interface might be the only way to get at the data, but live
systems tend to grow clients.  Soon, you have external processes
handling data interchange with other companies, processes sending
customers email...

This means two things:

1. You want to make sure that the database maintains as much data
integrity as it can, as long as that data integrity really must be
enforced across all applications.  For example, in an inventory
database, if an item's inventory level *always* equals all inventory
receivings minus all shipments, then that's a good candidate for a
rule enforced by a trigger in the database.

2. On the other hand, be careful of business logic that isn't
universal creeping into the database.  For example, for the web
application, you might send an email to a user when they register.
But do you *really* want to do *exactly the same thing* on a bulk load
of new users from an external source?

In other examples, page-to-page flow is probably not a great candidate
for encoding in the database; I would think that it makes far more
sense for the database to store the state of the various business
objects, and let the PHP application decide what to display to the
user.  Similarly, formatting is often a better idea in PHP, since you
may have more information about the right kind of formatting.  (Kind
of a shame, since PostgreSQL's data type text formatting is in many
ways superior to PHP's!)

However, a business rule that is designed to prevent bad data from
entering the database is a good candidate from being enforced in the
database.

Lastly, as a matter of preference, I don't like putting things into
the database that can block for extended periods, like sending email.
I think those are better put into external processes that run against
the database.  (And, of course, putting things that can block for an
extended period into the web application isn't good either.)

Here's one concrete example of a decision I made recently; of course,
I may have made the wrong one. :)  Customers on this side can search
across a large number of different types of entities, including
catalog items, catalog categories, product buying guides, articles,
etc.  The design required that these be presented in particular ways,
separate one from the other.  I could have implemented a procedure in
the database which took the search and returned the results, but I
decided that would be pushing too much of the UI display use case into
what should be a data store.  Instead, the application does separate
queries for each type, and unifies the results.  (This does have a
negative performance characteristic, since the application has to make
multiple trips to the database instead of calling one function, but it
wasn't significant enough to be a problem.)

Hope this helps!
--
-- Christophe Pettus
    xof@thebuild.com

On 2009-08-19, Christophe Pettus <xof@thebuild.com> wrote:

> In other examples, page-to-page flow is probably not a great candidate
> for encoding in the database; I would think that it makes far more
> sense for the database to store the state of the various business
> objects, and let the PHP application decide what to display to the
> user.  Similarly, formatting is often a better idea in PHP, since you
> may have more information about the right kind of formatting.  (Kind
> of a shame, since PostgreSQL's data type text formatting is in many
> ways superior to PHP's!)

I often do formatting in the query that retrieves the data.

> Here's one concrete example of a decision I made recently; of course,
> I may have made the wrong one. :)  Customers on this side can search
> across a large number of different types of entities, including
> catalog items, catalog categories, product buying guides, articles,
> etc.  The design required that these be presented in particular ways,
> separate one from the other.  I could have implemented a procedure in
> the database which took the search and returned the results, but I
> decided that would be pushing too much of the UI display use case into
> what should be a data store.  Instead, the application does separate
> queries for each type, and unifies the results.  (This does have a
> negative performance characteristic, since the application has to make
> multiple trips to the database instead of calling one function, but it
> wasn't significant enough to be a problem.)

If they are independant you can reduce latency by putting all those
requests one after another in a single asynchronous query using pg_send_query()
and then "peeling" the results off as they arrive. with (multiple calls to
pg_get_result())

or if they all return the same type just one big query made by
unioning the small ones together,