We have 0/1/2 for gender but also have tlkpSex or something like that. It has the id and the string we want to use, then our queries just make sure that data.gender=tlkpSex.gender. Good luck! Natalie On 11/7/06, Tony Grimes <thelist@xxxxxxxxxxxxxx> wrote:
Why not build the options into your data model? Instead of using integers for gender, use a varchar field that stores 'Male' and 'Female'. You can ensure data integrity by adding a check constraint to the column. If the presentation might change depending on context, you can create gender reference table with columns like short_name, long_name and abbreviation and use a foreign key to reference it from the main table. I try to use natural keys (i.e. Male,Female) instead of surrogate keys (1,2) whenever possible. It makes the database information more readable and you're not constantly picking through code to figure out what '3' means. Hope that helps, Tony On 11/7/06 2:19 PM, "Vignesh M P N" <manivig@xxxxxxx> wrote: > Hi > > > > I am facing a common problem which any developer querying the database would > face. > > > > In our web applications wherever we have more than one standard options for > a field, we usually denote them as integers. Say, for gender, we store it as > 1 or 2, but we display that as male or female in the user interface. So far > I had been handling this translation in the presentation layer ie., just > before displaying the data in the table, I check if the retrieved is "1" and > then translate it to "male" and so on. But this becomes clumsy when we have > lots of such standard options and when we need this translation in multiple > places in the application. > > > > So now I am thinking of adding an abstract layer which does all the > querying, retrieving and translation; and then return to my presentation > layer, so that if my presentation layer just calls a function in the > database abstract layer with the required query parameters, it gets back a > resultset with the translations. I hope this is a very common problem every > developer faces. > > > > I would like to have your guidance on this. I understand that a resultset > object is not easy to replicate. How do I make these translations and store > them back in an object and return it to the presentation layer? > > > > Or do we have existing PHP libraries which serve this purpose? Could you > suggest me a better way of solving this problem? > > > > Please help me on this. > > > > Thanks > > Vignesh. > > > > > > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
