'Twas brillig, and Jay Blanchard at 12/08/09 17:32 did gyre and gimble:
I'm interested to know why you consider this to be very flexible and how

this leaves the selection in the database's hands?

Flexible because I can connect to more than one database on a server
using one connection without having to re-issue a select_db command,
especially in a code container requiring connection to multiple

Fair point, but I would say that in the majority of cases an app pretty much connects to one database. I personally have exceptions to that rule, so I fully appreciate that this is not always the case and some people may see more of this type of setup than others, but I think it probably holds for the majority.

In this case it doesn't provide any extra flexibility - that's why I asked :) I guess it's only flexible if you are are dealing with a multi-db system. Even then it's arguably more flexible to keep a primary db selected and use it sans db prefix and use only the "other" databases in a fully "namespaced" way. (as this keeps flexibility of changing db easily - without the need for a wrapper.

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

I am unsure of what you're after here. We are only using a hard-coded
example but we can certainly improve this by using a class or function.

True, but arguably unnecessary overhead - especially in the "one db app" common case. Not necessarily significant, but it all adds up.

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.

Sure it is, unless you have to connect to more than one database in any
given code container. Consider this, I include a database server
connection (one file) and I do not have to do a select_db in other
subsequent files if I include the database name in the SQL query itself;

include("inc/dataConnect.inc"); // containing server connection only

Now in foo.php would you rather;

$theDatabaseSelected = select_db('database', $dbc);
$theQuery = "SELECT foo FROM bar WHERE glorp";


$theQuery = "SELECT a.foo FROM database.bar a WHERE glorp";

Now consider that I have to get information from more than one database
(on the same server) in a single container for display. Do you want to
issue the select_db each time?

$theDatabaseSelected = select_db('database', $dbc);
$theQuery = "SELECT foo FROM bar WHERE glorp";

$theNextDatabaseSelected = select_db('nextDatabase', $dbc);
$theQuery = "SELECT glorp FROM foo WHERE bar";

Or would it be easier to do this?

$theQuery = "SELECT a.foo FROM database.bar a WHERE glorp";
$theNextQuery = "SELECT a.glorp FROM database.foo a WHERE bar";

Aside from the incorrect db name :p, it is arguable easier :)

I'm not ultimately suggesting that this isn't a useful technique at times (I do do this myself in some apps), but I still reckon that for the majority of applications, it's makes more sense to work with a known database at all times for your connection and avoid the whole db name whenever possible.

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.

Sure it is, if not you have to use PHP (select_db) to perform the
database selection which sends an additional query ('use database') to
the database system.

In other words, would you query all of the raw data out of the database
and use PHP to process that data when the database can do a much more
effective job of filtering out what you do not need?

Well that analogy is lost on me... I really don't see what the comparison of a select db statement vs a db delimited table in queries has to do with reading raw data out and processing it in PHP....

But regardless (and this is more of a nitpicking semantic thing than anything PHP/db related now!), if I let the "db do the work" then I set it up with certain information and then give it limited information repeatedly and let it work things out.

By setting it up with a select db and letting it figure out which schema I want my data from by not telling it in multiple individual queries, I'm very much letting the "db do the work".

If I tell it explicitly at all times what database to use then I'm doing the work that could have been offloaded to the database. And if your query system goes via a wrapper to put in the right db schema names (e.g. from a config file) as you suggested, then the work you are doing on each query is very much real work done in PHP (str_replace, regexp matching/replacing, concatenation or whatever).

So perhaps it depends on your view point and preconceptions and we're both coming at the "flexible" and "offloading" arguments with different starting views.

Anyway, I only asked out of curiosity which I think has been satisfied (i.e. ultimately I don't fully agree with you! :p).




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