On 2009-08-19, Christophe Pettus <x...@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, -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
