Best methodology for a common db/front end issue

[PokerMan]

Hi

A common situation is a database using an ID number for a table and the
front end code needing to read this same id and store it back when used in
foregin key tables.

For example:

database table

RoomType
-------------
RoomTypeId
RoomType

and assume values

RoomType
--------------
1 | DoubleBed
2 | SingleBed
3 | Penthouse
etc

What i do is read that into my code and make an enum like:

enum RoomType{
DoubleBed,
SingleBed,
Penthouse
}
Is there a better way than this? My concern is what if the ids of the
roomtype table were ever changed? My code assumes they will never change and
so i just put my front end in sync with the ids. Am i using the right or an
acceptable methodology here?

[=?Utf-8?B?Q2lhcmFuIE8nJ0Rvbm5lbGw=?=]

I you intend to be able to administer the list of roomtypes then you need to
use objects rather than enum entries. If you dont ever want to be able to
change the list without doing a software build/test/release cycle, then this
is acceptable.
--
Ciaran O''Donnell
http://wannabedeveloper.spaces.live.com
"PokerMan" wrote:

Hi

A common situation is a database using an ID number for a table and the
front end code needing to read this same id and store it back when used in
foregin key tables.

For example:

database table

RoomType
-------------
RoomTypeId
RoomType

and assume values

RoomType
--------------
1 | DoubleBed
2 | SingleBed
3 | Penthouse
etc

What i do is read that into my code and make an enum like:

enum RoomType{
DoubleBed,
SingleBed,
Penthouse
}
Is there a better way than this? My concern is what if the ids of the
roomtype table were ever changed? My code assumes they will never change and
so i just put my front end in sync with the ids. Am i using the right or an
acceptable methodology here?

[PokerMan]

I presume you mean use an object as in, load in the roomtypes from the db,
store in an object or struct and then use those vars throught my app yes?

And no i dont expect the variables to ever be changed, but you never expect
something to not happen until it happens. I am just making sure i am ready
and aware of a worst case scenario here really.
"Ciaran O''Donnell" <Ci************ @discussions.mi crosoft.comwrot e in
message news:34******** *************** ***********@mic rosoft.com...

>I you intend to be able to administer the list of roomtypes then you need
to
use objects rather than enum entries. If you dont ever want to be able to
change the list without doing a software build/test/release cycle, then
this
is acceptable.
--
Ciaran O''Donnell
http://wannabedeveloper.spaces.live.com
"PokerMan" wrote:

>Hi

A common situation is a database using an ID number for a table and the
front end code needing to read this same id and store it back when used
in
foregin key tables.

For example:

database table

RoomType
-------------
RoomTypeId
RoomType

and assume values

RoomType
--------------
1 | DoubleBed
2 | SingleBed
3 | Penthouse
etc

What i do is read that into my code and make an enum like:

enum RoomType{
DoubleBed,
SingleBed,
Penthouse
}
Is there a better way than this? My concern is what if the ids of the
roomtype table were ever changed? My code assumes they will never change
and
so i just put my front end in sync with the ids. Am i using the right or
an
acceptable methodology here?

[Otis Mukinfus]

On Fri, 2 Feb 2007 15:08:27 -0000, "PokerMan" <no****@pokerca t.co.ukwrote:

>I presume you mean use an object as in, load in the roomtypes from the db,
store in an object or struct and then use those vars throught my app yes?

And no i dont expect the variables to ever be changed, but you never expect
something to not happen until it happens. I am just making sure i am ready
and aware of a worst case scenario here really.

Howdy PokerMan,

When developing software for businesses or even individuals for that matter,
never, never, never say, "It will never change.". If you write durable code you
may find the room type changing when the new owner buys the hotel and implements
HIS/HER business logic.

Good luck with your project,

Otis Mukinfus

http://www.otismukinfus.com
http://www.arltex.com
http://www.tomchilders.com
http://www.n5ge.com