Мне было поручено создать приложение, которое позволяет администраторам изменять содержимое входной формы пользователя (т. Е. Добавлять произвольные поля), содержимое которых хранится в базе данных. Передумайте переменные шаблона Think Modx / WordPress / Expression Engine.
Подход, который я рассматривал, заключается в реализации конкретных таблиц, где спецификация согласована (например, профили пользователей, пользовательский контент и т. Д.) И некоторые общие таблицы данных полей (то есть текст, логические) для хранения неспецифических значений. Формы (и поля модели) будут сгенерированы путем первого запроса таблиц и получения соответствующих столбцов, хотя я еще не подумал о том, как настроить проверку.
Я взглянул на эту проблему, и это, по-видимому, указывает на подход типа EAV, который, как мне кажется, из моего краткого исследования, может быть большим бременем, чем блага, которые принесет его гибкость.
Однако я прочитал несколько сообщений, в которых говорится, что это опасный маршрут:
Как создать общую базу данных, макет которой может меняться со временем?
Динамическая схема базы данных
Я был бы признателен за некоторые советы по этому вопросу, если кто-то даст
С уважением
SWK
Я создал очень большую базу данных EVA много лет назад (PHP с PostgreSQL). Получилось отлично, но это был большой проект ($$$). Все формы были полностью динамичными, с версией формы / поля, публикацией рабочих процессов, сопоставлением динамической отчетности и т. Д.
Основы EVA достаточно просты. Получение данных не является сложной. Но форма управления версиями и отчетности … вы можете потратить годы на правильное решение.
Если бы я делал это снова сегодня, я бы изучил использование одного из новых решений NoSQL ( http://en.wikipedia.org/wiki/NoSQL#Document_store ). Я бы хотел создать класс стиля DTO, который можно было бы передать генератору формы. «Модификация» формы фактически изменит DTO. Затем я буду настаивать на том, что DTO в базу данных документа / объекта.
Кроме того, по мере того, как вы создаете альфа-решение, подумайте о том, как разрешать тестовые примеры, которые охватывают потребности в версировании и отчетности.
Вот пример того, что я имею в виду: простая «Запросить форму вопроса».
Теперь вам нужно создать отчет (csv). Все становится сложным. Как ты делаешь это?
Мы решили эту проблему с версией на уровне поля со ссылками на их предыдущие версии. Кроме того, система отчетности требовала от конечного пользователя собрать определение источников данных отчета перед запуском. (привязка полей отчета к полям данных и т. д.).
Однако с документами DB я бы предположил, что вы можете сделать это по-другому. Я считаю, что новые DB, такие как CouchDB (другие?), Имеют механизм, созданный для решения этих проблем.
Удачи!!
При разработке профилей пользователей в моем последнем webapp я выбрал подход Key / Value table . Вот как выглядит мой дизайн БД:
Users table with fixed columns: id login name regdate Таблица пользователей, связанная с таблицей профилей (профиль пользователя HasMany).
Profiles table with different data: user_id field value
Таким образом, пользователь может добавить любое дополнительное поле в свой профиль. Например:
user_id = 1 field = 'Facebook' value = 'http://facebook.com/...'
а также
user_id = 1 field = 'Stackoverflow' value = 'http://stackoverflow.com/user/...'
и так далее..
В зависимости от ваших потребностей, возможно, не стоит даже поднимать поля формы на уровень «DB fields». Вместо этого вы можете сериализовать эти поля в (по существу) динамическом блоке и сохранить его в БД. Это НЕ рекомендуется, если у вас есть люди, которым необходимо запрашивать эти динамические поля вне вашего приложения (т. Е. Дизайн БД является частью более широкого публичного контракта с интегрированными системами), но если вы просто используете приложение для простого поиска эти динамические поля или если какие-либо возможности агрегирования / поиска в пределах полей являются незначительными, я бы это рассмотрел (в настоящее время эти возможности для CPU). Я использовал шаблон много раз, и у меня – до сих пор – никогда не приходилось рефакторировать. (однако я могу понять случай, когда вам может понадобиться).