У меня есть приложение, которое продается как SAAS нескольким клиентам.Как и ожидалось, иногда клиенты хотят настроить некоторые области приложения, добавив свои собственные поля , в частности область, связанную с отслеживанием действий / проектов.Мы допускаем небольшое количество этого в настоящее время.Он обрабатывается путем хранения имен дополнительных полей для каждого клиента в базе данных с идентификатором для каждого поля.Любые значения затем сохраняются во второй таблице, в которой есть столбец для каждого потенциального типа данных (строка, дата и т. Д.).Эта таблица ссылается на идентификатор настраиваемого поля и ключ объекта, к которому оно прикреплено.Таким образом, мы в конечном итоге храним все данные настраиваемых полей в одной таблице.Я не был бы слишком обеспокоен этим, если бы это было ограничено небольшим количеством полей для нечетного клиента, но теперь это рассматривается как возможность для продаж и обслуживания клиентов быстро настроить приложение для отдельных клиентов, а в некоторых случаяхполучить больше настраиваемых полей, чем было изначально для рассматриваемого элемента.
Я убедил людей, что пока мы должны отложить эти масштабные настройки, и я в целом считаю, что если вы хотитеТакое поведение вы должны построить правильно, т.е. создать соответствующие таблицы базы данных и т. д. Был еще один вопрос, который упоминает 2 способа реализации этого в базе данных здесь .Одно из решений похоже на изложенное выше.Другой - иметь в таблицах кучу избыточных полей для настройки, называемых «Текст1», «Текст2», «Дата1», «Дата2» и т. Д., Которые затем могут использоваться пользователями в соответствии с требованиями, переименовывая их в графическом интерфейсе.
Iбыло интересно, хотя, Как кто-то еще решил эту проблему?какие ограничения были для их решения?и любые предложения для дальнейшего чтения я мог бы сделать.
ура,