If you are dong as two seperate queries, I recommend using a
transactional table type setting the read isolation mode to repeatable
read and doing both your queries within a single transaction.
(David, sorry about the double send)
On 5/10/07, David T. Ashley <dashley@stripped> wrote:
> On 5/10/07, James Tu <jtu@stripped> wrote:
> > David:
> > I definitely can get the result set using one query, but what I do
> > with the result set has me thinking about breaking it up into two
> > queries.
> <Technical Details Omitted>
> Ah, OK, I misunderstood. You want to (get two results, each of which is
> useful individually) rather than (issue two queries, then iterate in PHP to
> combine the query results).
> Two queries seem fine in that case.
> Just one caution: be aware that another process (such as a web user) can
> sneak in in between your two queries and modify the database and render the
> two sets of query results inconsistent with one another.
> To give you an example, suppose you issue three queries in order (I'm going
> to botch the syntax here):
> SELECT COUNT(*) FROM USERS; (call this A)
> SELECT COUNT(*) FROM USERS WHERE IDX <= 10; (call this B)
> SELECT COUNT(*) FROM USERS WHERE IDX > 10; (call this C)
> It is very possible (in the presence of other simultaneous database
> activity) that A != B + C.
> It depends on the application whether this is significant.
> Table locking is the easiest way to prevent this if it matters.
- michael dykman
- All models are wrong. Some models are useful.