php-general Digest 26 Oct 2011 01:43:16 -0000 Issue 7537
Topics (messages 315419 through 315426):
Re: Geo IP Location help needed...
315419 by: Daniel Brown
Re: Exporting large data from mysql to html using php
315420 by: Jim Giner
315422 by: Jason Pruim
315423 by: Jim Giner
315424 by: Jason Pruim
315425 by: Bastien
315426 by: David Robley
Re: Friday Distraction
315421 by: Tedd Sperling
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Mon, Oct 24, 2011 at 21:07, DealTek <deal...@gmail.com> wrote:
>
> Q: Is there some code that can ALWAYS tell the country name of the IP?
More often than not, you will get accurate, real-time (as in, not
static and potentially stale from a database) results using a direct
WHOIS query. If you're on Linux without safe_mode enabled in PHP:
<?php
$ip = $_SERVER['REMOTE_ADDR'];
$country = trim(`whois $ip | grep -i country`);
if (!isset($country)) {
echo 'Country undetermined for IP: '.$ip.PHP_EOL;
} else {
echo $country.PHP_EOL;
}
?>
The above will work in situations where some copies of a geoIP
database may not. An example of this would be recent allocations of
the 184 blocks. Plus, if an IP is allocated to an entity in the US,
you can get the state to which the IP was registered. Note that, in
many cases, this isn't the state in which the IP actually terminates,
but in the case of small and local ISPs, academic institutions, et
cetera, it's pretty accurate.
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--- End Message ---
--- Begin Message ---
I disagree. It's not about "tuning the queries", it is more about the appl.
design that currently thinks it SHOULD do such huge queries.
My approach would be to prompt the user for filtering criteria that
automatically would reduce the result set size. Although at this time I
believe the OP mentioned that the db is just telephone numbers so that
doesn't leave much room for filter-criteria.
--- End Message ---
--- Begin Message ---
Jason Pruim
li...@pruimphotography.com
On Oct 25, 2011, at 10:51 AM, Jim Giner wrote:
> I disagree. It's not about "tuning the queries", it is more about the appl.
> design that currently thinks it SHOULD do such huge queries.
>
> My approach would be to prompt the user for filtering criteria that
> automatically would reduce the result set size. Although at this time I
> believe the OP mentioned that the db is just telephone numbers so that
> doesn't leave much room for filter-criteria.
>
>
Yes it is just phone numbers... The only select that I'm running on the entire
site is related to the pagination... A simple:
$sqlCount = "SELECT COUNT(*) FROM main WHERE state = '{$state}'";
which limits it to everything inside the state... Unfortunately if you look at
the possibilities, it's still quite a large dataset... 89 million :)
The rest of the query's will be much more limited to areacode, exchange, and in
some cases the full phone number... Maybe the better way to do it would be not
to count the records.... But set a variable with the total count... That way I
don't have to load all the data... The data amount won't change alot... Easy
enough to set a variable... Just need to see if I can integrate that with the
pagination...
Back to the drawing board! :)
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
Again why even do a detail query? Nobody is going to examine pages and pages
and etc.
Do a summary qry if u just need a count - no pagination there
jg
On Oct 25, 2011, at 6:26 PM, Jason Pruim <li...@pruimphotography.com> wrote:
>
> Jason Pruim
> li...@pruimphotography.com
>
>
>
> On Oct 25, 2011, at 10:51 AM, Jim Giner wrote:
>
>> I disagree. It's not about "tuning the queries", it is more about the appl.
>> design that currently thinks it SHOULD do such huge queries.
>>
>> My approach would be to prompt the user for filtering criteria that
>> automatically would reduce the result set size. Although at this time I
>> believe the OP mentioned that the db is just telephone numbers so that
>> doesn't leave much room for filter-criteria.
>>
>>
>
> Yes it is just phone numbers... The only select that I'm running on the
> entire site is related to the pagination... A simple:
> $sqlCount = "SELECT COUNT(*) FROM main WHERE state = '{$state}'";
>
> which limits it to everything inside the state... Unfortunately if you look
> at the possibilities, it's still quite a large dataset... 89 million :)
>
> The rest of the query's will be much more limited to areacode, exchange, and
> in some cases the full phone number... Maybe the better way to do it would be
> not to count the records.... But set a variable with the total count... That
> way I don't have to load all the data... The data amount won't change alot...
> Easy enough to set a variable... Just need to see if I can integrate that
> with the pagination...
>
> Back to the drawing board! :)
>
>
>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
--- End Message ---
--- Begin Message ---
Jason Pruim
li...@pruimphotography.com
On Oct 25, 2011, at 6:35 PM, Jim Giner wrote:
> Again why even do a detail query? Nobody is going to examine pages and
> pages and etc.
> Do a summary qry if u just need a count - no pagination there
> jg
The bosses wanted them to be able to page through the results... But I might
bring that up to them again... Working with 89 million records (With the number
going up and expanding in the future) could cause lots of issues in the long
run...
>
> On Oct 25, 2011, at 6:26 PM, Jason Pruim <li...@pruimphotography.com> wrote:
>
>>
>> Jason Pruim
>> li...@pruimphotography.com
>>
>>
>>
>> On Oct 25, 2011, at 10:51 AM, Jim Giner wrote:
>>
>>> I disagree. It's not about "tuning the queries", it is more about the
>>> appl.
>>> design that currently thinks it SHOULD do such huge queries.
>>>
>>> My approach would be to prompt the user for filtering criteria that
>>> automatically would reduce the result set size. Although at this time I
>>> believe the OP mentioned that the db is just telephone numbers so that
>>> doesn't leave much room for filter-criteria.
>>>
>>>
>>
>> Yes it is just phone numbers... The only select that I'm running on the
>> entire site is related to the pagination... A simple:
>> $sqlCount = "SELECT COUNT(*) FROM main WHERE state = '{$state}'";
>>
>> which limits it to everything inside the state... Unfortunately if you look
>> at the possibilities, it's still quite a large dataset... 89 million :)
>>
>> The rest of the query's will be much more limited to areacode, exchange, and
>> in some cases the full phone number... Maybe the better way to do it would
>> be not to count the records.... But set a variable with the total count...
>> That way I don't have to load all the data... The data amount won't change
>> alot... Easy enough to set a variable... Just need to see if I can
>> integrate that with the pagination...
>>
>> Back to the drawing board! :)
>>
>>
>>
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>
>>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
On 2011-10-25, at 6:56 PM, Jason Pruim <li...@pruimphotography.com> wrote:
>
> Jason Pruim
> li...@pruimphotography.com
>
>
>
> On Oct 25, 2011, at 6:35 PM, Jim Giner wrote:
>
>> Again why even do a detail query? Nobody is going to examine pages and
>> pages and etc.
>> Do a summary qry if u just need a count - no pagination there
>> jg
>
>
> The bosses wanted them to be able to page through the results... But I might
> bring that up to them again... Working with 89 million records (With the
> number going up and expanding in the future) could cause lots of issues in
> the long run...
Guarantee the bosses will never use it. If they had to page thru 89m records,
they'd rebel too
>
>
>>
>> On Oct 25, 2011, at 6:26 PM, Jason Pruim <li...@pruimphotography.com> wrote:
>>
>>>
>>> Jason Pruim
>>> li...@pruimphotography.com
>>>
>>>
>>>
>>> On Oct 25, 2011, at 10:51 AM, Jim Giner wrote:
>>>
>>>> I disagree. It's not about "tuning the queries", it is more about the
>>>> appl.
>>>> design that currently thinks it SHOULD do such huge queries.
>>>>
>>>> My approach would be to prompt the user for filtering criteria that
>>>> automatically would reduce the result set size. Although at this time I
>>>> believe the OP mentioned that the db is just telephone numbers so that
>>>> doesn't leave much room for filter-criteria.
>>>>
>>>>
>>>
>>> Yes it is just phone numbers... The only select that I'm running on the
>>> entire site is related to the pagination... A simple:
>>> $sqlCount = "SELECT COUNT(*) FROM main WHERE state = '{$state}'";
>>>
>>> which limits it to everything inside the state... Unfortunately if you look
>>> at the possibilities, it's still quite a large dataset... 89 million :)
>>>
>>> The rest of the query's will be much more limited to areacode, exchange,
>>> and in some cases the full phone number... Maybe the better way to do it
>>> would be not to count the records.... But set a variable with the total
>>> count... That way I don't have to load all the data... The data amount
>>> won't change alot... Easy enough to set a variable... Just need to see if
>>> I can integrate that with the pagination...
>>>
>>> Back to the drawing board! :)
>>>
>>>
>>>
>>>>
>>>> --
>>>> PHP General Mailing List (http://www.php.net/)
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>>
>>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Bastien Koert
905-904-0334
--- End Message ---
--- Begin Message ---
Jason Pruim wrote:
>
> Jason Pruim
> li...@pruimphotography.com
>
>
>
> On Oct 25, 2011, at 10:51 AM, Jim Giner wrote:
>
>> I disagree. It's not about "tuning the queries", it is more about the
>> appl. design that currently thinks it SHOULD do such huge queries.
>>
>> My approach would be to prompt the user for filtering criteria that
>> automatically would reduce the result set size. Although at this time I
>> believe the OP mentioned that the db is just telephone numbers so that
>> doesn't leave much room for filter-criteria.
>>
>>
>
> Yes it is just phone numbers... The only select that I'm running on the
> entire site is related to the pagination... A simple: $sqlCount = "SELECT
> COUNT(*) FROM main WHERE state = '{$state}'";
>
> which limits it to everything inside the state... Unfortunately if you
> look at the possibilities, it's still quite a large dataset... 89 million
> :)
>
> The rest of the query's will be much more limited to areacode, exchange,
> and in some cases the full phone number... Maybe the better way to do it
> would be not to count the records.... But set a variable with the total
> count... That way I don't have to load all the data... The data amount
> won't change alot... Easy enough to set a variable... Just need to see if
> I can integrate that with the pagination...
>
> Back to the drawing board! :)
>
Consider running EXPLAIN on all your queries to see if there is something
Mysql thinks could be done to improve performance.
Cheers
--
David Robley
Why do they put Braille dots on the keypad of the drive-up ATM?
Today is Prickle-Prickle, the 7th day of The Aftermath in the YOLD 3177.
--- End Message ---
--- Begin Message ---
On Oct 23, 2011, at 9:38 PM, tamouse mailing lists wrote:
>>
>> http://reflectionbeads.com/i/design-your-own
>
> That's a very interesting site. Surprising that it doesn't use a lick
> of PHP to do what it's doing, given what you wrote below.
How do you know that? Just to be argumentative, the entire thing could have
been written in PHP -- remember PHP can write Javascript.
Additionally, I know that this company uses PHP/MySQL for their backend scripts
-- because I've consulted for them.
> Well, okay, PHP is all that and a bag of chips, but it's not the ONLY
> player in this field. There are several languages that can do all that
> PHP does, some more elligantly, others less so. But really, there is
> *no* functionality in PHP that I haven't been able to also accomplish
> in Ruby, Perl, C++, or Java. Not that I would necessarily pick those
> languages over PHP for any given job.
Perhaps, but I KNOW it can be done in PHP and means something to me.
In addition, elegance is found in the skill of the programmer. Crap can be
written in any language.
> As for having PHP part of an IT cirriculum, I say RIGHT ON. A lot of
> these students will be going off to doing things where they may be
> asked to put together a web site for someone, and not knowing the
> tools is going to be painful. There are so many people out there
> hacking away at PHP and web sites that are doing a terrible job of it
> having seen some GAWDAWFUL PHP in my day -- which is one thing PHP
> more prone to than some of those other languages, by the way. But
> teaching them programming *skills* and *knowledge* rather than just
> how to rub two spoons together and swing a rubber chicken to get the
> server going again is a lot more useful to them.
"Spoons and Rubber Chickens" are better than some of the junk I've seen taught.
As I've told my students, "I can teach you the basics, but the real teacher is
you behind the keyboard."
Cheers,
tedd
--- End Message ---
