> An agent goes to an interface that reveals a list of customers from a
>database. These customers have provided referrals which now reside in a
>database. The agent selects a referral which is processed by an intermediary
>script which sets a flag in the database saying that "this agent" is, has,or
>will be contacting this referral (to prevent duplicate contact). Then this
>redirects to the referral's interface where the details about this referral
>are revealed.
The things is...
If these are all done by header("Location: ...") then you are needlessly
chewing up an awful lot of HTTP connections.
HTTP connections are, I think, a very limited and over-strained resource on
a busy site.
Now, the price *might* be "worth it" for maintainability...
OTOH -- I suspect you could simply include 'processing.inc' in Interface B
and have code that's just as maintainable without chewing up two/three/four
times as many HTTP connections/processes.
You can't scale up when you waste HTTP connections.
As far as atomicity (not letting the user abort) goes, I suspect that is
really better handled by transactions or, in a very crude way,
register_shutdown_function to check that all the results "tie out".
Actually, modular design and clear interface/API/back-end design often
obviate most of what beginners think they need transactions for, and a
couple well-placed (and well-thought-out) flags/time-outs can get rid of the
rest, until you actually get to the canonical "checkbook" (or any money)
example... You can do those the hard way, but it's usually not as good a
solution as a real transaction.
This is just my opinion, though, and I've often seen paradigms under fire
for all the wrong reasons. "It won't scale up" is meaningless for a
botique/niche site that won't every *NEED* to scale up. And yet you often
see a Manager insisting on doing it "that way", while wasting a zillion
people-hours on lame features and poor design layout and...
Ah well. Enough on that topic. I quit looking for a day job so I wouldn't
have to worry about that kind of junk any more. :-)
--
Like Music? http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
