Number of If statements on a page?

[UKSBD]

I have a dynamic counties page where the county pulled is dependend
on the referral string.

As I have about 120 counties listed this means the same dynamic page
creates 120 pages.

If I create If Statements to pull a unique paragraph of text about each
county, is there a limit to how many IF Statements can be used on the
page?

To do all 120 Counties I would have to use 120 IF Statements, would that
cause a problem with the page?

Would I be better of adding another string to the Counties table in the
database, adding a parragraph of text in each one, and pulling the
content from there?

[shaunb]

Your probably better off using a switch case statement, they're a lot faster and more efficient than if statements, especially on a large scale like that. Its also a lot easier to read than if statements.

Hope that helps.

Shaun.

[Kev Jaques]

Hmm, don't think you actually need to use a switch/case or an if statement or an extra table column?

You are displaying a page based on the referral string therefore that takes care of your if statement as you are narrowing the result by this criteria so I see no need for any if statements.
You can pull a paragraph of text out of the main content column easily enough without adding a new column and replicating data or using if statements
I do see the need for you to sanitize the input string and perhaps do a retrieval of counties which you can match the input string to avoid any xss/sql injection issues

[ozbon]

The other way you could do it is use an include file.

That way you have a separate file for each county - it only has to contain the relevant paragraph - and based on the referrer, do something like

<p>Generic 'on every page' text</p>
<?php
$county = $_GET["county"];
// Ideally do some sanitisaton here, just to make sure it's always in the same format etc.
include ('includes/counties/$county.php');
?>
<p>Generic 'on every page' text</p>

That makes it pretty easy to maintain as well - if you want to change the text for a county, you know where to find it.

As others have said, the other option would be to use a database table for the same thing, so you check the table for a county equivalent to $county - if it's there, put in the contents of that record, if not put in nothing.

Both methods will work just fine though.

[edmondscommerce]

how about something like this:


<?php
$whitelist=array(
'county1',
'county2',
'county3',
'county4',
etc..
);

$county='yorkshire';
if(in_array($_GET['county'], $whitelist)){
$county=$_GET['county'];
}
$county=mysql_real_escape_string($county);
$info = mysql_fetch_assoc(mysql_query("select * from table where county = '$county'"));

[ozbon]

how about something like this:


<?php
$whitelist=array(
'county1',
'county2',
'county3',
'county4',
etc..
);

$county='yorkshire';
if(in_array($_GET['county'], $whitelist)){
$county=$_GET['county'];
}
$county=mysql_real_escape_string($county);
$info = mysql_fetch_assoc(mysql_query("select * from table where county = '$county'"));


Well, it does involve setting up a big (already 120 rows) array for "whitelist" purposes,which seems rather a hassle.

Personally I'd use something like

$county = strtolower($_GET["county"]);
$county = [sanitise_function]($county);
$query = "SELECT * FROM table WHERE county='$county' LIMIT 1";
$result = mysql_query($query,$connection);
$row = mysql_fetch_row($result);
$cid = $row["county_id"];
if ($cid!="") {
$par = $row["county_text"];
echo "\n<p>$par</p>\n";
}

[UKSBD]

<snipped>

You can pull a paragraph of text out of the main content column easily enough without adding a new column and replicating data or using if statements

<snipped>



Thanks, but I haven't really got any main content in there yet.
I have a county table with just 2 columns at the moment, County and
Country. I can simply add another Colum and paste a unique paragraph of
text for each county in to it and then just pull that.
Does that make sense?

[UKSBD]

Personally I'd use something like

$county = strtolower($_GET["county"]);
$county = [sanitise_function]($county);
$query = "SELECT * FROM table WHERE county='$county' LIMIT 1";
$result = mysql_query($query,$connection);
$row = mysql_fetch_row($result);
$cid = $row["county_id"];
if ($cid!="") {
$par = $row["county_text"];
echo "\n<p>$par</p>\n";
}


The page is .ASP, but I will probably do something similar after creating a
new column in the counties table.

[Kev Jaques]

These are just examples right guys? Using * within any sql query is bad (unless dev/testing) But you knew that already ;)
Lots of people take examples at face value and adopt them as good practices, you only have to see those kinds of examples from well known vendors to realise it's not good practice.
Bit of paranoia kind of thing but don't trust userinput is key!
Setting up the whitelist into the array can be done with a sql query too, it's often better to ONLY allow what you do know than to try and combat against what you don't know.
A default county can be put through in the case of nothing matching the whitelist.
Also no good doing the examples in code as that would assume the OP is using PHP and that may not be the case.

[edmondscommerce]

hey maybe he really does need everything from the table :-)

yeah the whitelist approach is maybe a hassle but its very secure and very easy to understand

compare that with

preg_replace('%[^a-z]%i', '', $_GET['county']);

not quite as intuitive for the average coder and might still cause problems or require further validation

[edmondscommerce]

another thought re the whitelist approach


$whitelist=array();
$q=mysql_query("select county from counties");
while($r=mysql_fetch_assoc($q)){
$whitelist[]=$r['county'];
}

etcetc
not a hassle, only slightly more expensive in terms of processing and definitely secure.

[ozbon]

These are just examples right guys? Using * within any sql query is bad (unless dev/testing) But you knew that already ;)

It's not always bad - in this case, there's only three columns in the OP's database (including "county_text" column) and he's using all of them. So * is the best option.

In fact, I'd go so far as to say that * is useful in a lot of cases - so long as it's used sensibly. If you're using (in my experience) more than 50-60% of the recordset, use * rather than naming every field individually.

Bit of paranoia kind of thing but don't trust userinput is key!
Absolutely, which is why both my code examples said exactly that, to make sure it was sanitised before being used.

Also no good doing the examples in code as that would assume the OP is using PHP and that may not be the case.
Yep - that's totally true (as the OP did eventually say they're using ASP not PHP) although it does still give a useful guideline on what needs doing.

[Kev Jaques]

Pseudo code at this level was more than adequate which is why I just phrased it rather than coded it, I had a feeling the OP was using ASP as he had some other queries a while back ;)

Gonna have to disagree with you on Select *

Having worked for some big clients with big databases with mission critical data and in a big team of developers - select * would never cut it in a production environment.
Typical example is Schema changes - although these should be kept to a minimum on production databases there is total merit to have robust integral specific business rules in place.
If you use select * you are introducing further problems downline if schema changes do occur as you could also be joining on other tables too, if you add/change or remove columns from the tables/queries/procs and do not conduct project scope to identify where those queries are used with recordsets etc.. then you will introduce some really bad practices and sloppy coding. - That would also not pass a peer dev review in 99% of most teams (well should not if the lead dev is worth his salt ;) )

Not only that but you also introduce lack of optimisation with the optimiser not being able to look at column indexes effectively and there will also be increased memory and bandwidth usage.

[ozbon]

Gonna have to disagree with you on Select *

Having worked for some big clients with big databases with mission critical data and in a big team of developers - select * would never cut it in a production environment.

As I said in the previous post, it depends on what's being used, and the size of the database table involved.

I'd agree when it comes to large/huge tables and/or large numbers of rows in the recordset - I can't see Facebook (for example) using Select * . But then again, in certain circs even they do, I suspect - the user's profile page would be a perfect example, where you're using a good 75-85% of the recordset.

If you use select * you are introducing further problems downline if schema changes do occur as you could also be joining on other tables too, if you add/change or remove columns from the tables/queries/procs and do not conduct project scope to identify where those queries are used with recordsets etc.. then you will introduce some really bad practices and sloppy coding. - That would also not pass a peer dev review in 99% of most teams (well should not if the lead dev is worth his salt ;) )

The best lead dev I ever worked with had a motto "There's no such thing as an absolute rule". He used Select * where it was relevant, and could argue the point that it worked better/easier than identifying all the columns.

[FireFleur]

You can use as many if and case selects as you like and the system can handle.

But what you would normally do is create a lookup table:

So:

lookup = {
'country1' : 'country one description',
'country2' : 'country two description',
'country3' : 'country three description',
...
'country999' : 'country nine hundred and ninety nine description'
}

country = 'country2'

if country in lookup:
print lookup[ country ]