Варианты обработки часто меняющейся формы данных

Question

Какие существуют возможные варианты работы с часто меняющимися формами данных?

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

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

• Создайте новый объект, пользовательский интерфейс и набор таблиц для каждой версии.Это, очевидно, самый наивный подход.
• Продолжайте добавлять все поля в один и тот же объект и таблицы БД, но показывать / скрывать их в зависимости от версии формы.После нескольких изменений это станет беспорядком.
• Создание определений форм, затем динамическое построение пользовательского интерфейса и сохранение данных в формате словаря (например, JSON / XML или, возможно, база данных, ориентированная на документы)будет слишком сложным для сферы применения этого приложения, особенно для пользовательского интерфейса.

Какие еще есть возможности?У кого-нибудь есть опыт в этом?Я ищу некоторые шаблоны проектирования, которые помогут справиться со сложностью.

Answer 1

Я думаю, что третий подход (XML) является наиболее гибким. Простая структура XML генерируется очень быстро и может быть легко проверена и проверена на соответствие XSD.

У вас будет таблица, содержащая XML в одном столбце, и год / версия, к которой относится этот xml.

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

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

Answer 2

Сначала я поговорю с вашими решениями выше, а затем дам ответ.

• Создание новой таблицы для каждого версия будет требовать нового программирование каждый год, так как вы будете не сможет динамически присоединиться к новый стол и включить новый колонны легко. Это кажется довольно очевидным и действительно делает этот выбор неудачным.
• Проблемы, которые вы упомянули при добавлении столбцы одинаковой формы:
  правильный. Кроме того, независимо от базы данных вы Использует имеет максимум на сколько столбцы он может обрабатывать и сколько байтов может быть подряд. Это может стать еще одной проблемой.
• Третий вариант, я думаю, ближе всего к тому, что вы хотите. я мог бы не хранить новые данные столбца в JSON / XML, если это не для дублирования увеличить скорость. Я думаю это ваш лучший вариант
• Единственный вариант, который вы не упомянули хранил все данные в 1 поле базы данных и использование XML для разобрать. Эта опция сделает это трудно запрашивать и писать отчеты против.

Если бы мне пришлось сделать это:

1. Первая таблица будет иметь ID столбца (отобранный), Имя, InputType, CreateDate, ExpirationDate и CssClass. я назвал бы это tbInputs.
2. Второй стол будет иметь 5 столбцов, ID, Input_ID (с FK для tbInputs.ID), Entry_ID (с FK для значение основной / исходной таблицы) и CreateDate. ФК в главная / оригинальная таблица позволит вам чтобы найти какие предметы были прикреплены к какая форма записи. Я бы назвал это таблица tbInputValues.
3. Если нет планировать иметь эту базовую таблицу тогда Я бы использовал простую таблицу, которая отслеживает дату создания, идентификатор создателя, и form_id.
4. После того, как вы их получите, вам просто нужно создать динамическую форму, которая возвращает все активные в данный момент входы и отображает их. Я бы поместил все динамические элементы управления в некоторый контейнер, такой как <div>, поскольку он позволит вам проходить через них, не зная имени каждого элемента. Затем вставьте в tbInputValues ​​идентификатор входа и его значение.
5. Создание формы для добавления или удаления вход. Это будет означать, что вы бы не много, если любое обслуживание работать каждый год.

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

Answer 3

Для этого конкретного приложения мы решили разобраться с проблемой, как будто существует одна форма, которая постоянно растет. Из-за природы формы это казалось более естественным, чем более явное разделение. У нас будет отображение поля year-> для частей приложения, которым необходимо знать, какие данные для какого года.

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