Hi,
I'm working on a project that historically contains around 40 enums. In the
database various fields refer to the int values of these enums, but of
course ref integrity is not enofrced and when looking at the db we can't
tell what the value in a field represents. The other problem is that our
enums are currently all stored in a single class, which means that because
of no visibility constraints the enums are often used out of context e.g. A
CarEngine enum being used instead of a BikeEngine enum.
What I'd like to do is:
1) store the enums in the database so that we can enforce ref integrity. I
don't want to have to create 40 odd tables to store these values either. The
actual int value of the enum is unimportant as we won't be performing enum
addition (like CarEngine.4Cyli nder + CarEngine.Petro l).
2) dynamically create several classes within individual projects to allow us
to restrict visibility of the enums to within a project.
I have considered using three tables to store them - one for the class, one
for the enum type and one for the enum value and then (somehow) dynamically
building the class at compile time, but I have no idea how to do this!
Also, it does leave the problem of still not enforcing the ref integrity
100% i.e. the CarEngine field could store a BikeEngine enum value and still
enforce basic referential integrity as they're both enum values, albeit of
different types. Is it possible to enforce ref integrity in such a way to
prevent this?
The values held in the enum will not be changed between code releases and so
do not need to be truly dynamic. I would rather not have to hard code in
strings in our code to refer to the database.
Any clues about how to go about this or any better ideas / nice URLs to look
at?
Hope you're still following me!
Martin
I'm working on a project that historically contains around 40 enums. In the
database various fields refer to the int values of these enums, but of
course ref integrity is not enofrced and when looking at the db we can't
tell what the value in a field represents. The other problem is that our
enums are currently all stored in a single class, which means that because
of no visibility constraints the enums are often used out of context e.g. A
CarEngine enum being used instead of a BikeEngine enum.
What I'd like to do is:
1) store the enums in the database so that we can enforce ref integrity. I
don't want to have to create 40 odd tables to store these values either. The
actual int value of the enum is unimportant as we won't be performing enum
addition (like CarEngine.4Cyli nder + CarEngine.Petro l).
2) dynamically create several classes within individual projects to allow us
to restrict visibility of the enums to within a project.
I have considered using three tables to store them - one for the class, one
for the enum type and one for the enum value and then (somehow) dynamically
building the class at compile time, but I have no idea how to do this!
Also, it does leave the problem of still not enforcing the ref integrity
100% i.e. the CarEngine field could store a BikeEngine enum value and still
enforce basic referential integrity as they're both enum values, albeit of
different types. Is it possible to enforce ref integrity in such a way to
prevent this?
The values held in the enum will not be changed between code releases and so
do not need to be truly dynamic. I would rather not have to hard code in
strings in our code to refer to the database.
Any clues about how to go about this or any better ideas / nice URLs to look
at?
Hope you're still following me!
Martin
Comment