'Twas brillig, and Jay Blanchard at 12/08/09 17:32 did gyre and gimble:
[snip]
I'm interested to know why you consider this to be very flexible and how
this leaves the selection in the database's hands?
[/snip]
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
databases.
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.
[snip]
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).
[/snip]
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.
[snip]
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.
[/snip]
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";
Or;
$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.
[snip]
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.
[/snip]
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).
Cheers
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
