zencart style countries table, in php programming should we refer the country by id?

blackhorse

I am using zencart style countries table in my project such as for countries in address book etc. When refer the country, I used the coutries_id such as in my address book programming.

Here is the question, when I dealing with the special cases such as if the countries is usa or canada, due to in the whole site programming, I refer the country by its id, such as in the countries drop down menu, the id is the value of every option of the countries drop down menu.

So I detect if a country is usa by to see if its id is 223, if a country is canada by to see if its id is 38.

If this involve to detect many other countries, then I will get the id and then do a sql search get the ISO code for that id when i need to know which country is which.

But many of my projects will be to just to see if the country is USA or Canada (id as 223 or 38), or Not usa or canda.

I can keep using the same countries table, maybe add some new countries or change some countries' names. But usa will still be id 233 and canada is still 38.

In this situation:

1) should I hard code in this 223 and 38 for easy and quick detect if it is usa or canada?

2) should I call the sql every time to get the iso code from id and then detect to see if it is usa or canada?

3) create the global value for usa and canada countries id from the database and use this global value over the site?

In theory, the option 3) is better than 2) is better than 1).

But in practice, what is your approach?

I had been selecting the options preferred by theory before, but sometime, I think selecting the options by practice will be better. Like I had designed my own systems like the zencart style, design for multi-langauges usage, and if it is one langauge, then just not use the multilangauge feature. This is preferred by theory because its flexiblity. But in practice, large pecent of my projects are one language only. In practice, if I design for 1 language, it will be easy to use, fast, stable, and easy to update. For the flexibility of multi-langauges issues, I can chose only take the 1 language projects. Or I can deal with multi-langauge cases (modify from the most current 1 langauge version etc.) case by case.

thanks

mpb001

1 and 3 can be catered with a constant instead. Magic numbers/globals are really bad and I would actually order them with 2 first if I was forced to use one option and I could not use constants. Globals never ever ever need to be used, especially for things that do not change after being set. A config object passed around is better as that can be locked after setting.

2) You can use a static array in a function/method call to cache repeated lookups per page request. If your database is set up with query caching the results to the lookups will be cached anyway so it is a negligable thing you are trying to avoid on such a small static table. Even without query caching it's still does not rate below using globals.

//Static lookup caching function
function CachingLookUp( $id , $dummy_value = '' )
{
    static $index = array(); 
    if( !isset( $index[ $id ] ) )
    {
        //Set with value from db or whatever
        $index[ $id ] = $dummy_value;
    }
    else
    {
        print_r( $index );
    }   

}

CachingLookUp( 1 , "ancd" );
CachingLookUp( 1 );

CachingLookUp( 2 , "dbdbdbd" );
CachingLookUp( 2 );

The thing that comes to mind is a multi national/multi language system should try to be completely agnostic. Though if you do decide to do special cases( for us and canada ) it should be abstracted from the main process of page creation.

eg.

//Special case lookup function
define( "COUNTRY_CAN" , 38 ); 
define( "COUNTRY_US"  , 223 );
function SpecialLookUp( $id )
{
     switch( $id )
     {
         case COUNTRY_CAN :
             return "ca";

     case COUNTRY_US :
         return "us";

     default :
         return ;//do db lookup or whatever          
 }
}

The thing to do is not go down the premature optimisation route but look at what you are doing, see where you might need to optimise in the future and leave youself with an easy elegant way to do it.

http://en.wikipedia.org/wiki/Optimization_(computer_science)

"When to optimize" bit for more

blackhorse

Thanks!

I have been trying to avoid using global values.

I may stick with the option 1) for now.

It will be easy to mass replace the codes ==223 with ==$usa_id, ==38 with ==$canada_id later on if I want to update to option 2).

And I can have a script to be included to the pages which the replacements will happen and assign the new $usa_id and $canada_id values in the included script.