Brian W

I know that LIKE conditions are slower than a strait equals conditions. In the case that I'm trying to find a particular user's information and I know their first name, I could do something like: SELECT * FROM users WHERE name LIKE '$name%'; And if I knew their state too: SELECT * FROM users WHERE state_id = '$state_id' AND name LIKE '$name%'; The Question is: I would expect that because the state condition comes first, MySQL would only run the LIKE condition on the dataset that matched the state which should increase the speed. Am I correct?

Hmm, the brackets may be having it return a boolean... so rather than removing the brackets use them for the mysql_real_escape_string function that you really should use. $suffix = mysql_real_escape_string($_POST['suffix']);

Thats what I'm hoping. Some of the Sr. Devs on here are amazing and know of tricks I'd never think of.

Are you working with error_reporting( E_ALL) ? You should be, it helps track down issues. Posting the lines around where the problem is or the entire code (with sensitive data **** out) will help you get helped. Side note: be sure you to use mysql_real_escape_string on $_POST['suffix'] as well.

exit; kills your application right there... nothing else is processed from that point on. So, your code says that if their is any error messages then simple kill the entire page without spitting out the messages for the user to see. I'd help more, but frankly your code is seems to me that its far from working at all. Please post the functions: field_validator(), checkPass(), and cleanMemberSession(). That should help us with your overall problem.

AbraCadaver, I of course realize I could call the function directly and that would be faster. This issue I have is that I am working with mysqli_stmt::bind_param( string $types , mixed &$var1 [, mixed &$... ] ) which accepts basically limitless params. There are solutions to doing this dynamically, but they all utilize the call_user_func_array which like I said is less than desirable. I don't want to waist too much time spinning my wheels on alternatives, but then again I'm not stuck until I get it done or anything so I'm willing to take some time finding the best solution.

Is there a call_user_func_array() alternative other than eval()? With the shear genius of some of the individuals on this forum, I'd expect that if there is an alternative, someone here would know it. Any tips or insight greatly appreciated. Thanks Background (blah blah blah) I'm being kinda picky on efficiency and performance since I will be looking at possible hundreds of executions a request... so I'd like to avoid using the above mentioned functions since they take ~3x and ~10x longer (according to a this comment).

Drupal uses the $_SERVER superglobal to store connection information (though not the connection object itself that I know of). This does seem to be a valid use as what you are storing is the connection information for the mysql server. Maybe not, maybe Drupal's architects are missing the point too. Using mysql_connection(), you can use most any of the mysql_* functions without passing in the connection resource which makes it an easy choice... mysqli however isn't as friendly, though its so much faster and (imo) fits in with oop better. From my understanding, using the persistent option with mysqli will cache the connection and reuse the same connection repeatedly until the request is done. If this is true, a factory wouldn't need to access a global connection object because their would be very little resources sacrificed for mysqli to return the cached connection repeatedly. I'm thinking that using a persistent connection and storing hostname, username, password, and database in $_SERVER is the solution, but then again I'm not all that familiar with building factories... I did see a tutorial using the "singleton" structure, but didn't fully get it I guess. Maybe someone has a link to an awesome singleton for mysqli Thanks for all the input!

I know that... your missing my point. The idea isn't to carry it over multiple requests, but to have access to the same connection inside all of my objects on all scopes.

Interesting, $_SERVER is quite bulky... My Results Base 83144 putenv 83496 1 83552 "1" 83584 $_SER 94896 Multiple uses of $_SERVER did not increase the memory usage noticeably, but that first time does jump it. So PHP seems to ignore populating it unless you actually use it in your code. putenv doesn't seem to be required to drop stuff into the $_ENV global. I did this little test this morning: <?php $obj = new stdClass(); $obj->name = 'test'; $_ENV['obj'] = $obj; function test(){ echo $_ENV['obj']->name; } test(); ?> The memory usage is lower than $_SERVER (86632) but if you plan on using $_SERVER anywhere in your code you will end up using the memory. For a programming convention, not that globals aren't still under scrutiny, is a database connection more of a $_SERVER thing or a $_ENV?

although I misspelled it is a previous post, I do mean $_SERVER... you know, the one with HTTP_HOST & DOCUMENT_ROOT along with a bunch of other information about the machine and the file you're working with.

the question I guess is "why"? Whats the issue with using a $_SEVER to store a connection object to access globally to avoid reopening the same connection repeatedly?

advantage of global access... right?

Why (if it is) bad practice to use the $_SERVER array to store variables like the database hostname, username, password, etc... or even a mysqli object? I know the whole anti lazy coding, but is there another reason not to go about things like this?

Results from doing "while($i<1000)" 0.0076823234558105 7.6823234558105E-6 34.950205564499 0.034950205564499