Jump to content

Recommended Posts

For typical mysql data base processing {many times in ONE page}.

I do the following, (but I do not know if this is safe).

 

$con = mysql_connect(HostName, UserName, UserPassword); {once in the page at the top most level}

.

.

INSERT

.

.

SELECT

.

.

UPDATE

Example: mysql_query("UPDATE `user` SET `telephone` = '".$telephonenumber."' WHERE `email` = '".$email."'");

.

.

But I DO NOT have any update statement after any of my operation to ensure data is properly transfered

.

.

Finally I let the page to end by itself and thus DO NOT have the following at all

mysql_close($con);

 

Please let me know if this safe, I fear what might happen in a heavy traffic day.

Link to comment
https://forums.phpfreaks.com/topic/140607-solved-old-habits-die-hard/
Share on other sites

function q($query,$assoc=1) {

$r = @mysql_query($query);

if( mysql_errno() ) {

  $error = 'MYSQL ERROR #'.mysql_errno().' : ' . mysql_error(). '< / small>< br>< VAR>$query< /VAR>';

  echo($error); return FALSE;

}  if( strtolower(substr($query,0,6)) != 'select' ) return array(mysql_affected_rows(),mysql_insert_id());

$count = @mysql_num_rows($r);

if( !$count ) return 0;

if( $count == 1 ) {

  if( $assoc ) $f = mysql_fetch_assoc($r);

  else $f = mysql_fetch_row($r);

  mysql_free_result($r);

  if( count($f) == 1 ) {

  list($key) = array_keys($f);

  return $f[$key];

  } else {

  $all = array();

  $all[] = $f;

  return $all;

  }

} else {

  $all = array();

  for( $i = 0; $i < $count; $i++ ) {

  if( $assoc ) $f = mysql_fetch_assoc($r);

  else $f = mysql_fetch_row($r);

  $all[] = $f;

  }

  mysql_free_result($r);

  return $all;

}

}

 

The Syntax for q is quite simple

eg: q(SQL QUERY);

eg :: < ?= q("SELECT * FROM `tbl_whoever` WHERE `id` = '$return_result[userid]' LIMIT 1;"); ?>

eg :: < ?= q("SELECT COUNT(*) FROM `tbl_whoever` WHERE `id` = '$return_result[userid]' LIMIT 1;"); ?>

 

 

I wrote this years ago and still use it, hopefully some help to you

Thanks for sharing.

 

I am able to do the fundamental operations.

 

My concern is with the following

 

.
.
.But I DO NOT have any update statement after any of my operation to ensure data is properly transfered
.
.
Finally I let the page to end by itself and thus DO NOT have the following at all
mysql_close($con);
.
.

 

Is it a safe practise.

 

I am worried about heavy traffic days "Data jumbling or Data appearing to be missing for other pages just before current page updates"

 

Or am I a paranoid?

im pretty sure the only concern would be the mysql_close(), but then im sure php closes any connections itself (i think its more for multiple connection handlers etc for transfering db data between servers or w/e).

 

don't quote me on that though. lol.

Uniflare,

 

Yes, you got my point, I am uncertain over this.

 

Can any Guru advise on this please, so that we could get the exect picture.

 

:)

 

Maybe we can see this way: PHP Server & MySQL server are they (i) a multi concurrent thread operator or (ii) a FIFO single page Qd operator. If FIFO single page Qd, we can have no concern at all over my matter.

 

:)

PHP will close mysql connections when the page has finished executing, so there is no need to do it manually. The only reason you might want to close it, is if there is a lot of processing after you have done all the database stuff, in which case the connection would be open for a lot longer than necessary.

 

Not sure what you mean about the update statement. To check that inserts/updates ran ok, just check the output of mysql_query (it return false on error). See http://uk.php.net/manual/en/function.mysql-query.php

If it doesn't return false, then the data has been saved successfully.

directed @ the people above talking about mysql connections

 

they are right as when PHP exits, all resources, (sql result resources, sql connection resources, socket connections, etc) are all destroyed

 

you need not close mysql connections unless you are going to use more than 1 connection, and you want to cut down on the weight you're putting on your server.. if you have 10 connections open you can assume that the script will run 10 times slower, but since scripts process so quickly it might go from like 1ms to 10ms and you'd hardly notice the difference..

 

but take that 10ms and multiply it by the amount of users on your website and that = heavy on your server.

 

although I'm not exactly sure if my timing is ACCURATE so accuracy ninjas please don't attack me for saying 10ms when its really 5.89273 ms for 10 connections lol..

 

so if you're terminating a mysql connection then trying to use it later, its obvious there is going to be an errror..

Thank you people.

 

After discussion, I think it is fine to leave connection open till end of page (natural closure).

 

Once some one told me, if I have a for loop and there is 10 mysql database accesses (1 per loop), if I open and process and close connections 10 times, I am reducing the effeciency of machine, thus (advised to) open once to process 10 times then let the page close after which. He mentioned (this way) it is far more effeicent.

 

Please comment & correct me if I am wrong.

directed @ the people above talking about mysql connections

 

they are right as when PHP exits, all resources, (sql result resources, sql connection resources, socket connections, etc) are all destroyed

 

you need not close mysql connections unless you are going to use more than 1 connection, and you want to cut down on the weight you're putting on your server.. if you have 10 connections open you can assume that the script will run 10 times slower, but since scripts process so quickly it might go from like 1ms to 10ms and you'd hardly notice the difference..

 

but take that 10ms and multiply it by the amount of users on your website and that = heavy on your server.

 

although I'm not exactly sure if my timing is ACCURATE so accuracy ninjas please don't attack me for saying 10ms when its really 5.89273 ms for 10 connections lol..

 

so if you're terminating a mysql connection then trying to use it later, its obvious there is going to be an errror..

 

 

 

A connection adds virtually no overhead (CPU wise) when not using it.  When initializing it, there is overhead though.  Perhaps that's what you mean?

any extra un needed cpu time is worthless..

 

if you took a string that was 300k charslong.. which is possible.. and applied the following function 10 times to the string..

function abc($string) {

  return strlen($string);

}

then applied the above function 10 times to a string like "hello" you can assume that it would run slower on the first one than the second one.

 

now, thats because its more data for php to handle, having many resources you'd assume works the same way..

 

resources are exactly that, resources. You take a 10 mysql connections, the amount of memory to keep reference to the 10 mysql connections is much more than you'd expect php to need, even idle its like adding white feathers to a box of offwhite feathers and trying to seperate em in order to count em.

 

its going to take a while, but if its just 1 offwhite feather and 1 white feather, its much quicker to do this operation.

 

maybe I exagurated with 10x but any performance loss is performance loss..

 

that is why they created mysql_close() to free the allocated memory of that resource, before termination of PHP, to keep your scripts running efficiently.

 

is all I was tryna explain

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.