Page 1 of 1

Arranging <option> as last in <select> [SOLVED]

Posted: Mon Sep 24, 2007 9:48 am
by aceconcepts
Hi,

I have a <select> element that is populated with values from a MySQL database.

The list may consist of values such as "Mr, Mrs, Other, Dr".

My question is: how can I arrange the list so that "Other" displays last even if it is not last in the database table?

I dont really want to have to put an additional <option> after my loop.

Thanks.

Posted: Mon Sep 24, 2007 9:55 am
by aaronhall
If you're not already ordering the results, try adding a separate int 'order' column to the table and make the cell corresponding to "Other" a higher value than the rest. Append "ORDER BY `order`" to your query, but not before a LIMIT clause.

You'd normally not have these values stored in a database anyway unless you plan on changing them frequently.

Posted: Mon Sep 24, 2007 9:56 am
by Zoxive
Maybe a simple if Statement in your loop when your pulling out of the database.

Posted: Mon Sep 24, 2007 10:05 am
by onion2k
aaronhall wrote:You'd normally not have these values stored in a database anyway unless you plan on changing them frequently.
I don't agree with that. Even if they're not changed often the database is still the best place to keep them.

Posted: Mon Sep 24, 2007 10:16 am
by aceconcepts
Thanks for all the ideas.

I do like the idea of an IF statment in the loop...nice.

P.s. I like to keep lists like this in a database for the pure fact that its nice and straightforward, easy to amend/add new values.

Anyway, thanks for the posts.

Posted: Mon Sep 24, 2007 10:18 am
by aaronhall
onion2k wrote:
aaronhall wrote:You'd normally not have these values stored in a database anyway unless you plan on changing them frequently.
I don't agree with that. Even if they're not changed often the database is still the best place to keep them.
It probably depends on how static the information is, and if it's worth an extra query to the database to pull it out. Unless you're building a front end to manage that table, it's probably easier editing template files than it is incurring the extra overhead/code to be able to stick it into a table. It always depends on what's happening with that data afterwards anyway, so I was quick to classify this as non-database-worthy. I'm also thinking of the extra overhead to retrieve this info later on if it's associated with another table in the database.

Posted: Mon Sep 24, 2007 10:22 am
by aceconcepts
I know what you're saying about the "overhead". Sometimes I think is it really worth it!!!

I guess for its just normal practice or habit :D

Posted: Mon Sep 24, 2007 10:25 am
by aaronhall
As a generalization, if it makes life easier for the programmer, it almost always makes life more difficult for the computer running the code. :)

Posted: Mon Sep 24, 2007 2:13 pm
by onion2k
aaronhall wrote:
onion2k wrote:
aaronhall wrote:You'd normally not have these values stored in a database anyway unless you plan on changing them frequently.
I don't agree with that. Even if they're not changed often the database is still the best place to keep them.
It probably depends on how static the information is, and if it's worth an extra query to the database to pull it out. Unless you're building a front end to manage that table, it's probably easier editing template files than it is incurring the extra overhead/code to be able to stick it into a table. It always depends on what's happening with that data afterwards anyway, so I was quick to classify this as non-database-worthy. I'm also thinking of the extra overhead to retrieve this info later on if it's associated with another table in the database.
You've missed the main advantage of keeping things in the database. If you don't put something like the user titles into the database then every single time you output the user information (order receipts, CSV dumps of customers, emails to them, etc) you'll have to include your array of titles and convert the ID in the database into the text. If they're in the database they can be pulled out with an inner join. Coupled with some SQL concatenation you can build the user's real name as a single field. If you're using something a little cleverer than MySQL you can even create a view that has the users display name as a column. The advantage of keeping information in the database is so that the database to make use of it, it's got nothing to do with how easy it is to maintain really.

Posted: Tue Sep 25, 2007 11:47 pm
by aaronhall
I'm only arguing against keeping the list in a separate table, for exactly the reason you cited (inner joins are expensive). For a small, unchanging list like that, a SET field would be a lot more efficient even it if is a little more difficult maintain. This only requires maintaining the list in the add and edit forms, and spares you the extra table join every time you want to get a person's name.