'Twas brillig, and Jay Blanchard at 12/08/09 13:53 did gyre and gimble:
Jay Blanchard wrote:
SELECT a.foo, a.bar
FROM myDatabase.myTable a
WHERE you set other conditions here
All that is required is that you establish a connection to a server.
If I recall correctly, this will cause issues with replication in
MySQL... insofar as you perform amodifying query.
[/snip]
You're correct with regards to queries that modify on replicated
systems. If all you're doing is gathering data then this will work just
fine, is somewhat self-documenting (especially in lengthier code
containers), and very flexible. It also leaves the selection in the
database's hands, and as we almost always say, "let the database do the
work when it can".
I'm interested to know why you consider this to be very flexible and how
this leaves the selection in the database's hands?
If I were to implement this and they try some destructive testing/demo
on a sacrificial database, I'd have to use a whole other server instance
(as all the queries would hardcode in the db name).
Is it not more flexible if you omit the table name in every single query
and specify it once in your bootstrap/connection code? Thus doing tests
on other dbs etc. is a pretty simple switch of the connection code.
Also telling the db engine what database you want to use in every query
is not, IMO, leaving the selection in the the database's hands.
Just curious as to the rationale here :)
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
