Page 1 of 1

which one among these two is efficient way ...?

Posted: Thu Sep 14, 2006 11:30 pm
by rami
i am doing this
<select name="post">
<option value="clerk">clerk</option>
<option value="manager">manager</option>


and next

Code: Select all

<select name="pro_type"><option >select one</option>
<?php
require_once ('../../dbconnect.php');
$query = "SELECT post_id,post_name  from position";		
$result = mysql_query ($query);
while ($row = mysql_fetch_array ($result, MYSQL_ASSOC)) {
	echo "<option value=\"{$row['post_id']}\">{$row['post_name']}</option>\n";
}
?>
</select>
among two which one is efficient
if i do first one i see
it will take larger DB space as it is varchar
and may be comparision will be slower post like ...
and it will be static and i need to change in code to add post

but if i do second one
every time when i display total job profile
after doing
select * from jobs where job_id=$id;
i have to make query
pos_id=$row['post_id']};
select post_name from position where post_id=pos_id;

similary in single file i have many such field like country,experiecne,qualification...
that way i need some extra select for each such data
and i need table for each such field what to do

Posted: Fri Sep 15, 2006 12:38 am
by Christopher
I don't think you will notice and performace difference. You really don't need to think about performance issues when you have small fields like the 25 character ones that you have -- especially for small result sets like for <select>s. When you row lengths are several K in size and you are fetching hundreds or thousands of records then it may become an issue (or time for a bigger server).

Posted: Fri Sep 15, 2006 5:25 am
by rami
that means i can use either...

Posted: Fri Sep 15, 2006 5:38 am
by onion2k
Never hardcode options into a page unless you have no other choice. Always put them into a database table. It's a lot easier to add more, change the order, delete them, etc if they're in the database.

Posted: Fri Sep 15, 2006 6:10 am
by rami
onion2k wrote:Never hardcode options into a page unless you have no other choice. Always put them into a database table. It's a lot easier to add more, change the order, delete them, etc if they're in the database.
that way i will have lots of table
and for each i have to make query to display its realname
..
whats about that
i really will have lots of table for eg
one for gender,ocupation,education,location....

what to do

Posted: Fri Sep 15, 2006 6:30 am
by onion2k
rami wrote:
onion2k wrote:Never hardcode options into a page unless you have no other choice. Always put them into a database table. It's a lot easier to add more, change the order, delete them, etc if they're in the database.
that way i will have lots of table
and for each i have to make query to display its realname
..
whats about that
i really will have lots of table for eg
one for gender,ocupation,education,location....

what to do
I have websites with hundreds of database tables. It doesn't matter if there are lots of them. What does matter is being able to change things very easily .. and if the data is stored in a database table that's a trivial task.

Posted: Fri Sep 15, 2006 6:30 am
by GM
That's correct. Having lots of tables is not a bad thing - you say it as though it is!

You should have a table for each "kind" of data: A table of Occupations, a table of Locations etc. etc.

This means that if you want to add a new Location, you just have to add a row into the database, and you don't need to change your source code at all.

You probably don't need a table for Gender, since it can only take two possible values, and is unlikely to ever require more adding!

Remember, the more things you hardcode into your scripts, the more difficult it is to make changes. If ever you wanted to sell one of your scripts to someone, they would want to be able to manage the data as they want without ever having to touch your actual code.