Как разрешить гибкие поля формы HTML, но легко запускать отчеты SQL?

Question

Я создаю веб-сайт, который позволяет заявителям подавать заявки. Поля для формы заявки должны быть гибкими, чтобы можно было вносить изменения.

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

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

Так что я ищу некоторые предложения / рекомендации, если кто-то сделал подобные реализации. Спасибо.

Пример 1 (поле -> столбец):

форма заявки может иметь следующий вид Поля:

• имя
• фамилия

и соответствующая таблица базы данных должна смотрите как показано ниже:

• имя_папки nvarchar (255)
• фамилия nvarchar (255)

Пример 2 (пары ключ / значение):

• first_name (ключевой столбец), john (столбец значений), текстовое поле (тип)
• last_name (ключевой столбец), smith (столбец значений), текстовое поле (тип)

Я нашел несколько примеров, таких как polldaddy.com wufoo.com, которые позволяют создавать динамические веб / html формы, но я думаю, что в моем случае они бесполезны из-за требований к отчетности. И я думаю, что их реализация будет похожа на мой «пример 2».

Обновлен:

Я нашел этот проект (динамические формы mvc) , и я считаю, что концепции похожи на то, что мне нужно достичь. Я глубоко посмотрю на проект.

Answer 1

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

Хороший подход к решению проблемы с отчетностью состоит в том, чтобы иметь отдельные схемы базы данных для транзакционных (OLTP) и отчетных ( OLAP ) битов. Схема Differnet не означает другую физическую базу данных - хотя в какой-то момент может иметь смысл разделить их.

Тогда у вас будет какой-то процесс ETL , который перенес данные между ними (из источника OLTP в таблицы назначения OLAP).

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

Прелесть отдельной настройки OLTP / OLAP заключается в том, что оба ориентированы на то, чтобы хорошо выполнять свою соответствующую работу - без ущерба для другого.