'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.

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 :)



Colin Guthrie

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

Reply via email to