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

Question

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

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

1. Alter таблица счетов и добавить новый столбец вручную.

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

   если Эхо «Единый клиент Обязательное поле:» (пусто ($ строка [ «new_filed»])!) , $ Строки [ 'new_filed'];

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

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

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

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

Спасибо

Answer 1

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

Answer 2

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

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

таблица

счета * Содержит информацию, такую ​​как счет

• account_id // первичный ключ этой таблицы
• account_name
• account_status

таблица Client

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

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

Таблица client_field // будет содержать таблицу, которая может быть определена/config Ured

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

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

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

field_dropdown

• идентификатора // первичным ключом для этой таблицы
• FIELD_ID // иностранные key from client_field
• dropdown_value // значение, которое будет использоваться в выпадающем списке при выборе
• dropdown_description // описание, которое будет отображаться в списке
• dropdown_order // порядок элемента
• dropdown_status // флаг, является ли активным/неактивным

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

client_information

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

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

проблемы в разработке такого рода применения:

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

в ПРОФИ для этой конструкции:

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

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