Question

在过去30年左右的时间里，我一直在为之工作的公司建立了静态动态字段（我能想到的最佳术语）。

在一个例子中有更好的描述。我们在下面有一个员工对象：

Employee
{
    Employee Name
    Employee Number
    Address
}

我们的每个客户都有很多员工，但可能希望保存额外的数据 - 比如他们的宠物名称。我们没有宠物名称字段，因此可以选择为所有客户存储此字段，允许每个客户拥有不同的数据库（ugh），或允许使用动态字段。

我们采用了动态字段选项，但略有不同。

问题here正在寻求解决此问题的方法。在我看来，这是我们应该在我出生之前做出这个决定时所做的事情。

我们的实施如下：

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

我们有10到20个额外字段，在内部称为＆＃39; flexi字段＆＃39; （灵活的领域）。这些字段包含字符串值，其中config用于确定各个客户端的显示名称（例如FlexiField3 = PetName），字段类型（日期将始终以指定格式存储等）以及其他一些零碎的部分。

我想向我的老板建议我们放弃这个模型，转而回答here发现的问题。

我之前已经向老板提到过这个我不喜欢的事情，但对替代方案并不完全确定。我简要地建议了一个类似于：

的表格

CustomCustomerValues
{
    Table
    Key
    Type
    Value
}

示例条目为{Table = Employee，Key = EmployeeNumber，Type = Integer，Value = 1234}

我的老板带来了一个主要观点，这将阻止我们进一步追求这一点 - 报道。

我们的客户喜欢报道。水晶报告是最常见的。

是否可以很好地报告动态字段？目前报告对他们来说非常简单，因为它只是＆＃34;选择字段员工编号，员工姓名和Flexi字段2,3和4＆＃34;。如果我们有一些键值对，那么它如何用于报告应用程序？

Answer 1

可悲的是，我认为报道将不可避免地更加复杂。如果已知属性的名称，则可以向表中添加列（例如AttributeName）并连接到由此AttributeName列限制的CustomCustomerValues表。例如

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'

如果属性名称未知，它将再次变得更加复杂，您将不得不使用动态sql。

报告动态数据库字段是一个问题吗？

1 个答案: