Обработка динамических полей с помощью SQL Server

0

Предпосылки: Я работаю над проектом, который в настоящее время имеет бэкэнд 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.
Теги:
sql-server
reporting-services

1 ответ

1
Лучший ответ

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

Итак, с головы до головы вы бы:

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

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

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

Поделиться
  • 0
    Я думаю, я понимаю, что вы говорите. Вы имеете в виду, что я должен хранить динамические поля в таблице ключей / значений? Затем создайте таблицу common_form_field, которая содержит сходства между формами, и объедините их, чтобы получить динамические данные? Это имеет смысл для меня, но я надеялся избежать записи новой записи для каждого из этих динамических полей ... мне это кажется просто неэффективным.
  • 0
    Это было общее предложение. Насколько это будет эффективно, зависит от конкретного варианта использования. Будет ли много (разных) форм? Сколько раз будет использоваться данная форма? 100, 100000? Отчеты не запускаются часто, и это в основном среда с интенсивной записью? Манипуляции со строками довольно дороги в движке SQL, а объединения - нет. Индексы в правой колонке или представлении делают запросы очень быстрыми.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню