【问题标题】:How best to create custom fields per user/customer?如何最好地为每个用户/客户创建自定义字段?
【发布时间】:2009-09-21 14:39:51
【问题描述】:

我有一个应用程序作为 SAAS 出售给多个客户。可以预见,有时客户希望通过添加自己的字段来自定义应用程序的某些区域,特别是与操作/项目跟踪相关的区域。我们目前允许少量。它是通过在数据库中存储每个客户的附加字段的名称来处理的,每个字段都有一个 id。然后将任何值存储在第二个表中,该表具有每个潜在数据类型(字符串、日期等)的列。该表引用了自定义字段的 id 以及它所附加到的对象的键。通过这种方式,我们最终将所有自定义字段数据存储在一个表中。如果它仅限于奇数客户的少量字段,我不会太担心这一点,但现在它被视为销售和客户服务为个人客户快速定制应用程序的机会,在某些情况下是获得的自定义字段比有问题的项目上的原始字段多。

我已经说服人们我们现在应该推迟这些大规模的定制,我一般认为如果你想要这种行为你应该正确地构建它,即创建相关的数据库表等. 还有一个问题提到了在数据库here 中实现这一点的两种方法。一种解决方案类似于上面概述的解决方案。另一种是在要自定义的表上有一堆冗余字段,称为 Text1、Text2、Date1、Date2 等,然后用户可以根据需要在 gui 中根据需要重命名它们。

我想知道,其他人是如何解决这个问题的?他们的解决方案有什么限制?以及我可能会做的任何进一步阅读的建议。

干杯,

【问题讨论】:

    标签: user-interface customization field user-defined-fields


    【解决方案1】:

    我们还开发 SaaS,我们也有需要各种定制的客户。

    它或多或少对所有客户都有用,它有一个固定的实现。含义、表格和字段。通过属于用户包的某些访问权限启用或禁用该功能。

    当允许用户动态定义字段及其相关子字段以创建自己的表单时,我们也有不同的情况。它和它一样复杂。在这里,我们使用一种Entity Attribute Value model 来满足这些需求。

    这就是“企业”应用程序的特点,可能是它们的独特功能 - 客户想要一些异国情调的东西,我们不能拒绝。

    【讨论】:

    • 您是否使用实体属性值模型进行了任何优化以提高性能? (如缓存或索引等)
    猜你喜欢
    • 2014-08-02
    • 2012-01-15
    • 1970-01-01
    • 2023-01-09
    • 1970-01-01
    • 2020-03-20
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多