Как лучше создавать пользовательские поля для каждого пользователя/клиента?

Question

У меня есть приложение, которое продается как SAAS нескольким клиентам. Как и ожидалось, иногда клиенты хотят настроить некоторые области приложения, добавив свои собственные поля, в частности область, относящуюся к отслеживанию действий/проектов. Мы разрешаем небольшое количество этого в настоящее время. Он обрабатывается путем хранения имен дополнительных полей для каждого клиента в db с идентификатором для каждого поля. Затем любые значения сохраняются во второй таблице, которая имеет столбец для каждого потенциального типа данных (String, date и т. Д.). В этой таблице указан идентификатор настраиваемого поля и ключ объекта, к которому он присоединен. Таким образом, мы сохраняем все пользовательские данные полей в одной таблице. Я не был бы слишком обеспокоен этим, если бы он ограничивался небольшим количеством полей для странного клиента, но теперь его рассматривают как возможность для продаж и обслуживания клиентов быстро настроить приложение для отдельных клиентов, а в некоторых случаях получая больше настраиваемых полей, чем первоначально было в рассматриваемом предмете.

Я убедил людей в том, что мы должны удержать эти масштабные настройки на данный момент, и я, как правило, придерживаюсь мнения, что если вы хотите такого поведения, вы должны правильно его построить, то есть создать соответствующие таблицы базы данных и т. д. Был еще один вопрос, который упоминает два способа его реализации в базе данных here. Одно из решений аналогично описанному выше. Другой - иметь кучу избыточных полей в таблицах, которые должны быть настроены под названием Text1, Text2, Date1, Date2 и т. Д., Которые затем могут быть использованы в соответствии с требованиями пользователей, переименовавших их соответственно в gui.

Мне было интересно, но, Как кто-то еще решил эту проблему? какие ограничения были для их решения? и любые предложения для дальнейшего чтения, которые я мог бы сделать.

веселит,

Answer 1

Мы также разрабатываем SaaS, и мы также есть клиенты, которые хотят все виды настроек.

Если это более или менее полезно для всех клиентов, оно имеет фиксированную реализацию. Значение, таблицы и поля. Эта функция включена или отключена с помощью некоторого права доступа, которое принадлежит пакету пользователя.

У нас также есть другая ситуация, когда пользователям разрешено динамически определять поля и связанные с ними подполя для создания собственных форм. Это так же сложно, как и все. Здесь мы используем своего рода Entity Attribute Value model для удовлетворения этих потребностей.

Это то, что касается приложения «предприятие», возможно, их уникальная особенность - клиент хочет чего-то экзотического, и мы не можем сказать «нет».