2015-07-27 2 views
0

Фон: Я работаю над проектом, в котором в настоящее время есть сервер SQL Server и угловой интерфейс. Проект является относительно простым форматом приложения, где есть несколько форм, которые пользователь может передать на бэкэнд. Сейчас все работает отлично, но есть новое требование в конвейере, где они хотят, чтобы будущие формы были динамичными. Динамический в том смысле, в котором они хотят, чтобы администраторы могли добавлять/удалять поля из формы без какого-либо вмешательства.Обработка динамических полей с помощью SQL Server

Для прототипа, который я построил, я довольно много издевался над nosql db, сохраняя угловато-формально json obj, который описывает форму в одной таблице. Сейчас я обсуждаю, как фактически сохранить результаты этих форм. Я мог бы просто сохранить объект результата JSON этих форм в таблице результатов формы «один зонтик». Поэтому по существу возьмите ng-модель и подстройте ее, и сохраните ее в таблице результатов.

Вопрос:

Место, где я бегу в проблемы есть с отчетностью по результатам этих форм. Для отчетов потребуется считывать данные/распаковывать их в динамическую таблицу и затем запрашивать их по запросу. Я не очень хорошо знаком с SQL Reporting Services, но могу ли я создать общий отчет, который сможет распаковать JSON, запросить его и сгенерировать отчет?

В качестве альтернативы, существует рекомендуемый способ SQL Server для решения этой проблемы или так, как я делаю это лучший способ сделать это?

+0

Вы пишете ** SQL ** (язык структурированных запросов) и действительно ли это означает Microsoft ** SQL Server ** (фактический продукт)? Если да: добавьте тег 'sql-server', чтобы это стало ясно. Если нет: ** для чего нужна система баз данных? –

+0

Если вы не привязаны к SQL Server, вам может понадобиться посмотреть Postgres. Он обладает чрезвычайно эффективным хранилищем ключей/значений и очень мощной поддержкой JSON. –

ответ

1

Упаковка, распаковка и синтаксическая обработка данных не находится в рулевой рубке большинства двигателей SQL. Подойдя к нему с точки зрения SQL, вы по существу сохраняете пары name: value (динамические поля). Я собираюсь предположить, что все формы будут иметь некоторые минимальные общие данные, по крайней мере: создавать данные, создавать пользовательские формы, идентификатор и т.д.

Таким образом, с верхней части моей головы, вы бы:

Таблица, в которой описывается форма: pk, читаемое пользователем имя, список полей и т. Д. Таблица, в которой хранятся нединамические поля: pk, form_id и т. Д. Таблица, в которой хранятся динамические поля: form_id, name, значение и т. д.

Теперь отчет представляет собой простой запрос, соединяющий таблицу desc, статическую таблицу и динамическую таблицу.

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

+0

Думаю, я понимаю, что вы говорите. Вы имеете в виду, что я должен хранить динамические поля, в каком количестве, таблицу ключей/значений? Затем создайте таблицу common_form_field, которая содержит общие черты между формами и соедините их, чтобы отменить динамические данные? Это имеет смысл для меня, но я надеялся избежать записи новой записи для каждого из этих динамических полей ... просто кажется мне неэффективным. – JakeHova

+0

Это было общее предложение. Насколько эффективно это будет зависеть от вашего конкретного варианта использования. Будут много (разных) форм? Сколько раз будет использоваться данная форма? 100, 100 000? Часто ли отчеты не выполняются, и в основном это тяжелая среда для записи? Обработка строк довольно дорога в SQL-процессоре, а объединения не являются. Индексы на правильных столбцах или в представлении делают запросы очень быстрыми. – WPrecht

Смежные вопросы