Как создать динамическое поле для базы данных с помощью PHP

У меня есть многоклиентское приложение PHP, которое я написал. Это приложение имеет много объектов базы данных, как и любое другое приложение PHP. Но поскольку это многоклиентское приложение, каждый раз, когда мы подключаем нового клиента, у меня разные требования к клиенту. Есть пара общих объектов (они же учетные записи), в которых хранится большая часть клиентской информации. Но самое главное, каждый раз, когда я хочу добавить нового клиента в базу данных, этому новому клиенту потребуется новый столбец в добавленных базах данных учетных записей, потому что они будут иметь некоторые уникальные данные. Существуют стандартные обязательные данные (например, имя_учетной записи, статус...), но некоторые данные уникальны и помечены по-разному в зависимости от типа бизнеса клиента.

В настоящее время то, что я должен сделать, чтобы удовлетворить требования,

  1. Измените таблицу учетных записей и добавьте этот новый столбец вручную.
  2. отредактируйте PHP-скрипт, где я отображаю информацию об учетной записи и отображаю содержимое поля так

    if(!empty($row['new_filed'])) echo 'Обязательное поле для одного клиента: ' . $строка['новый_файл'];

  3. если поле доступно для редактирования, то мне нужно добавить правила в форму редактирования/добавления, чтобы выполнить проверку проверки данных перед сохранением.

Я пытаюсь создать интерфейсный инструмент, который будет делать это автоматически. Таким образом, я могу попросить администратора «не программиста» перейти к интерфейсному инструменту и добавить новое поле, и это поле будет отображаться в выбранном разделе выбранной страницы.

С помощью внешнего инструмента я хочу иметь возможность добавить настраиваемое поле с именем «brand_c» и сделать его типа varchar (100). Затем на странице под названием «account_info.php» в разделе «Другое» отобразите это поле с меткой «Бренд», только если клиент = «XYZ», поэтому, если данные принадлежат клиенту «ABC», не отображайте данные, так как этот столбец является пользовательским только для «XYZ».

Я понимаю, что это широкий вопрос, но я ищу любую помощь в том, как такую ​​​​вещь можно построить (с чего начать?). Это то, что делает большинство крупных CRM, например, Microsoft CRM Dynamic, Salesforce.com ...) имеют это. Как я могу спроектировать что-то подобное?

Спасибо


person Jaylen    schedule 13.09.2014    source источник
comment
Посмотрите на сводные таблицы или EAV (значение атрибута сущности). Это то, что вы ищете.   -  person Lauri Orgla    schedule 13.09.2014
comment
Загляните в хранилища Key-Value.   -  person kums    schedule 13.09.2014
comment
Другим способом вместо добавления столбцов (уникальных свойств для каждого клиента) было бы создание в отдельной таблице дополнительных свойств для каждого клиента. Затем создайте фактические значения для каждого свойства клиентом. Затем, возможно, сгенерируйте представление для клиентов, включающее соответствующие свойства. Неэффективно, но может помочь вам подумать об этом.   -  person Ryan Vincent    schedule 13.09.2014


Ответы (2)


Первый шаг, который вам нужно сделать, это правильно спроектировать таблицы, поэтому в основном вам нужно знать, как спроектировать таблицу для поддержки динамических полей, и поле сможет проверять/обрабатывать такие данные.

Что я сделал со своим приложением (динамическое приложение, в котором поля пользовательского интерфейса могут быть настроены в администраторе приложения), так это сохранение конфигурации в базе данных, каждый раз, когда происходит транзакция, страница будет получать конфигурацию для выбранного биллера и будет генерировать обязательные поля. и когда форма будет отправлена, приложение снова получит конфигурацию и выполнит проверку на основе настройки в client_field.

Таблица учетных записей * Содержит такую ​​информацию, как учетная запись

  • account_id //первичный ключ этой таблицы
  • название аккаунта
  • Статус аккаунта

Таблица клиентов

  • client_id // первичный ключ этой таблицы
  • account_id // внешний ключ: таблица учетных записей
  • имя клиента
  • client_status

вы можете добавить другой столбец для клиента в зависимости от ваших требований, но не добавляйте необходимые поля пользовательского интерфейса в эту таблицу, вместо этого создайте таблицу, как показано ниже.

client_field table //будет содержать таблицу, которую можно определить/настроить

  • field_id // первичный ключ этой таблицы
  • client_id // внешний ключ: клиентская таблица
  • field_name //имя поля, которое будет отображаться в пользовательском интерфейсе
  • field_title //появляется при наведении курсора на поле
  • field_datatype // это может быть текст, целое число, дата, логическое значение и т. д.
  • field_type // тип ввода поля: это может быть текстовое поле, средство выбора даты, раскрывающийся список и т. д.
  • field_required //флаг, указывающий, является ли поле обязательным
  • field_display //флаг, указывающий, будет ли поле отображаться/скрываться в пользовательском интерфейсе
  • field_defaultvalue //значение по умолчанию для установки при отображении страницы
  • field_minvalue //минимальное значение, которое поле примет: допустимо, только если dataytpe целое/двойное
  • field_maxvalue //то же, что и описание field_minvalue, вместо этого будет проверяться максимальное целочисленное/двойное значение
  • field_maxlength // максимальная длина поля
  • field_order //порядок поля в интерфейсе
  • статус поля //активировать или деактивировать поле

Вы можете добавить дополнительный столбец, но вам нужно убедиться, что он будет гибким и не будет избыточным.

скажем, у вас есть раскрывающийся список field_type, вам нужно создать другую таблицу, назовем ее

field_dropdown

  • id // первичный ключ для этой таблицы
  • field_id //внешний ключ от client_field
  • dropdown_value // значение, которое будет использоваться в выпадающем списке при выборе
  • dropdown_description //описание, которое появится в выпадающем списке
  • dropdown_order // порядок элемента
  • dropdown_status //отметить, активна/неактивна ли эта запись

Вам может быть интересно, как сохранить данные, если это так, данные должны быть сохранены в другой таблице, давайте назовем это

client_information

  • id //первичный ключ для этой таблицы:
  • client_id //внешний ключ из клиентской таблицы
  • field_id //внешний ключ из client_table.
  • value // значение из пользовательского интерфейса

таким образом, когда вы сохраняете нового клиента, каждое поле в поле client_field будет добавлять новую строку в таблицу client_information вместе со значением, вставленным пользователем

сложности при разработке такого рода приложений:

  • его довольно сложно разработать (много условий и карт, и требуется много времени)
  • вам нужно будет правильно настроить поля, чтобы он работал правильно
  • правильный дизайн системы, архитектура и поток, иначе это разрушит динамичность системы
  • вам понадобится надлежащая документация, чтобы вы понимали, что есть что.
  • процесс будет линейным для всех клиентов, кроме случаев, когда вы можете изменить свой собственный поток, сохранив их в базе данных

ПЛЮСЫ для этого дизайна:

  • после его завершения вам больше не требуется, чтобы разработчик добавлял дополнительный код, за исключением улучшения программного обеспечения, такого как функция, которая не поддерживалась на момент ее выпуска.
  • приложение будет динамическим, а добавление любого поля будет простым и удобным в обслуживании через модуль администратора

Я не говорю, что это НЕОБХОДИМО СДЕЛАТЬ, но это мое предложение о том, как разработать приложение, для которого требуются динамические поля данных, и, исходя из моего опыта разработки, оно работает хорошо, если оно хорошо спроектировано и разработано.

person rfpdl    schedule 13.09.2014

Вместо добавления дополнительных полей в качестве нового столбца в таблицу учетных записей вы можете создать новую таблицу, скажем, extra_data, например, со столбцами account_id, data_label и data_content. Таким образом, вы можете сохранить в этой таблице столько дополнительных фрагментов данных для каждой учетной записи и получить их в account_info.php.

person Schlaus    schedule 13.09.2014