Wed, Aug 12, 2009 at 10:37 AM, Ralph Deffke <ralph_deffke@xxxxxxxx> wrote: > I agree totally, are we not dicussing speed issues all the time? and then > we > recommend a code doing an unessesary job on every call? > > an ANSI selct db in the sql forces any database to run the internal select > db because there would be no check if the databse is the current one. > because, databasedevelopers can espext some smartness of us, the > programmers. its a lot off stuff to do for the database to select a > database. for shure, the database leafs that IN OUR hand to avoid to force > time consuming server resources. > > ralph > ralph_deffke@xxxxxxxx > > "Colin Guthrie" <gmane@xxxxxxxxxxxxxx> wrote in message > news:h5ug1h$tjb$1@xxxxxxxxxxxxxxxx > > '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 > > <?php $link = mysql_connect( /* settings */); mysql_select_db( 'database', $link); $result = mysql_query( 'SELECT * FROM <table>', $link ); What SQL was sent to the database? Looking at bin logs I've found this. 1. use database => mysql_select_db 2. use database: SELECT * FROM <table> => mysql_query The DB is usually a common bottle-neck for most applications. You can have several webservers, but can't do that with the DB... of course, you can have multiples slaves but just 1 master. is this the best way to send queries? What's the better and faster way? -- Martin Scotta
