Re: Database abstract layer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [PHP Home]     [PHP Users]     [Postgresql Discussion]     [Kernel Newbies]     [Postgresql]     [Yosemite News]

  Powered by Linux