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,
