如何最好地为每个用户/客户创建自定义字段？
我有一个应用程序作为 SAAS 出售给多个客户。可以预见的是，有时客户希望通过添加自己的字段来自定义应用程序的某些区域，特别是与操作/项目跟踪相关的区域。目前我们允许少量这样做。它是通过在数据库中存储每个客户的附加字段名称以及每个字段的 id 来处理的。然后，所有值都存储在第二个表中，该表为每种潜在数据类型（字符串、日期等）有一列。该表引用自定义字段的 id 及其所附加对象的键。通过这种方式，我们最终将所有自定义字段数据存储在一个表中。如果它仅限于少数客户的少量字段，我不会太担心，但现在它被视为销售和客户服务为个人客户快速定制应用程序的机会，并且在某些情况下是获得比相关项目最初的自定义字段更多的自定义字段。
我已经说服人们，我们现在应该推迟这些大规模定制，而且我通常认为，如果您想要这种行为，您应该正确构建它，即创建相关的数据库表等。另一个问题提到了在数据库中实现此操作的两种方法此处。一种解决方案与上面概述的类似。另一种是在表上有一堆要定制的冗余字段，称为 Text1、Text2、Date1、Date2 等，然后用户可以根据需要在 GUI 中根据需要重命名它们来使用它们。
但我想知道，其他人是如何解决这个问题的？他们的解决方案有哪些限制？以及我可能会做的进一步阅读的任何建议。
干杯，
I've got an application which is sold as a SAAS to multiple customers. Predictably, sometimes customers want to customise some areas of the application by adding their own fields, specifically the area relating to Action/Project tracking. We allow a small amount of this currently. It is handled by storing the names of additional fields for each customer in the db with an id for each field. Any values are then stored in a second table which has a column for each potential data type (String, date etc.). This table references the id of the custom field, and the key of the object it is attached to. In this way we end up storing all the custom field data in a single table. I'd not be too concerned about this if it was limited to a small amount of fields for the odd customer, but it's now being seen as an opportunity for sales and customer service to quickly customise the application for individual customers and in some cases were getting more custom fields than there was originally on the item in question.
I've convinced people that we should hold off on these large scale customisations for now, and I'm generally of the opinion that if you want this sort of behaviour you should build it properly, ie creating the relevant database tables etc. There was another question which mentions 2 ways of implementing this in the database here. One solution being similar to that outlined above. The other is to have a bunch of redundant fields on the tables to be customised called Text1, Text2, Date1, Date2 etc which can then be used as required by the users renaming them as appropriate in the gui.
I was wondering though, How anyone else has solved this issue? what limitations there were to their solution? and any suggestions for further reading I might do.
cheers,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们还开发 SaaS，并且我们也有需要各种定制的客户。
如果它或多或少对所有客户有用，它就有一个固定的实现。含义、表和字段。该功能通过属于用户包的某些访问权限来启用或禁用。
当允许用户动态定义字段及其相关子字段来创建自己的表单时，我们还有一种不同的情况。它很复杂。在这里，我们使用一种实体属性值模型来满足这些需求。
这就是“企业”应用程序的特点，可能是它们独特的功能——客户想要一些异国情调的东西，我们不能拒绝。
We also develop SaaS and we also have customers that want all kinds of customizations.
Where it more or less could be useful to all customers, it has a fixed implementation. Meaning, tables and fields. The feature is enabled or disabled through some access right that belongs to the user package.
We also have a different situation when users are allowed to dynamically define fields and their related subfields to create their own forms. It is as complex as it goes. Here we use a sort of Entity Attribute Value model to address these needs.
That is the thing with "enterprise" application, probably their unique feature - a customer wants something exotic and we can't say no.