Search code examples
domain-driven-designlookupdbtable

best practices with code or lookup tables


[UPDATE] Chosen approach is below, as a response to this question

Hi,

I' ve been looking around in this subject but I can't really find what I'm looking for...

With Code tables I mean: stuff like 'maritial status', gender, specific legal or social states... More specifically, these types have only set properties and the items are not about to change soon (but could). Properties being an Id, a name and a description.

I'm wondering how to handle these best in the following technologies:

  • in the database (multiple tables, one table with different code-keys...?)

  • creating the classes (probably something like inheriting ICode with ICode.Name and ICode.Description)

  • creating the view/presenter for this: there should be a screen containing all of them, so a list of the types (gender, maritial status ...), and then a list of values for that type with a name & description for each item in the value-list.

These are things that appear in every single project, so there must be some best practice on how to handle these...

For the record, I'm not really fond of using enums for these situations... Any arguments on using them here are welcome too.

[FOLLOW UP]

Ok, I've gotten a nice answer by CodeToGlory and Ahsteele. Let's refine this question.

Say we're not talking about gender or maritial status, wich values will definately not change, but about "stuff" that have a Name and a Description, but nothing more. For example: Social statuses, Legal statuses.

UI: I want only one screen for this. Listbox with possibe NameAndDescription Types (I'll just call them that), listbox with possible values for the selected NameAndDescription Type, and then a Name and Description field for the selected NameAndDescription Type Item.

How could this be handled in View & Presenters? I find the difficulty here that the NameAndDescription Types would then need to be extracted from the Class Name?

DB: What are pro/cons for multiple vs single lookup tables?


Solution

  • I have decided to go with this approach:

    CodeKeyManager mgr = new CodeKeyManager();
    CodeKey maritalStatuses = mgr.ReadByCodeName(Code.MaritalStatus);
    

    Where:

    • CodeKeyManager can retrieve CodeKeys from DB (CodeKey=MaritalStatus)
    • Code is a class filled with constants, returning strings so Code.MaritalStatus = "maritalStatus". These constants map to to the CodeKey table > CodeKeyName
    • In the database, I have 2 tables:
      • CodeKey with Id, CodeKeyName
      • CodeValue with CodeKeyId, ValueName, ValueDescription

    DB:

    alt text http://lh3.ggpht.com/_cNmigBr3EkA/SeZnmHcgHZI/AAAAAAAAAFU/2OTzmtMNqFw/codetables_1.JPG

    Class Code:

    public class Code
    {
        public const string Gender = "gender";
        public const string MaritalStatus = "maritalStatus";
    }
    

    Class CodeKey:

    public class CodeKey
    {
        public Guid Id { get; set; }
        public string CodeName { get; set; }
    
        public IList<CodeValue> CodeValues { get; set; }
    }
    

    Class CodeValue:

    public class CodeValue
    {
        public Guid Id { get; set; }
    
        public CodeKey Code { get; set; }
    
        public string Name { get; set; }
        public string Description { get; set; }
    
    }
    

    I find by far the easiest and most efficent way:

    • All code-data can be displayed in a identical manner (in the same view/presenter)
    • I don't need to create tables and classes for every code table that's to come
    • But I can still get them out of the database easily and use them easily with the CodeKey constants...
    • NHibernate can handle this easily too

    The only thing I'm still considering is throwing out the GUID Id's and using string (nchar) codes for usability in the business logic.

    Thanks for the answers! If there are any remarks on this approach, please do!