Question

For the last 30 years or so, the company I have been working for has set up static dynamic fields (the best term I can think of).

It's better described in an example. We have an employee object below:

Employee
{
    Employee Name
    Employee Number
    Address
}

Each of our clients has many employees, but may wish to save extra data - say their pets name. We do not have a field for pet's name so the choice is to either store this field for all clients, allow each client to have a different database (ugh), or allow for dynamic fields.

We took the dynamic field option, but a slight variation of it.

The question here is asking for a solution to this problem. In my opinion this is what we should have done when this decision was first made before I was born.

Our implementation below:

Employee
{
    Employee Name
    Employee Number
    Address
    FlexiField1
    FlexiField2
    ...
    FlexiField20
}

We have somewhere between 10 and 20 extra fields which are referred to internally as 'flexi fields' (flexible fields). These fields hold string values with config determining the display name (eg FlexiField3 = PetName) to the individual clients, the field type (dates will always be stored in a specified format etc) and a few other bits and pieces.

I would like to suggest to my boss that we move away from this model in favor of the answer of the question found here.

I've mentioned this before to my boss as something I didn't like, but wasn't completely sure on the alternatives. I briefly suggested a table looking something like:

CustomCustomerValues
{
    Table
    Key
    Type
    Value
}

An example entry would be {Table=Employee, Key=EmployeeNumber, Type=Integer, Value=1234}

My boss came back with 1 main point that would prevent us from pursuing this any further - reporting.

Our clients love reports. Crystal reports being the most common.

Is it possible to report nicely on dynamic fields? Currently reporting is very simple to them as it's simply "Pick fields Employee Number, Employee Name and Flexi Field 2, 3 and 4". If we had some key-value pair how would this work for reporting applications?

Was it helpful?

Solution

Sadly I think reporting will inevitably be more complex. If the names of the attributes are known you can add a column to your table (eg AttributeName) and join to the CustomCustomerValues table restricting by this AttributeName column. eg.

SELECT 
    Employee.EmployeeName,
    Employee.EmployeeNumber,
    Employee.Address,
    CustomCustomerValues.Value as PetsName
FROM 
    Employee
    LEFT JOIN CustomCustomerValues ON 
        Employee.EmployeeNumber = CustomCustomerValues.Key
        AND CustomCustomerValues.Table = 'Employee'
        AND CustomCustomerValues.AttributeName = 'PetsName'

If the attribute names are unknown it will be more complex again, and you would have to employ dynamic sql.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top