Опции для обработки часто изменяющейся формы данных
Что некоторые возможные проекты должны иметь дело с часто изменяющимися формами данных?
У меня есть основное веб-приложение CRUD, где основная форма ввода данных ежегодно изменяется. Таким образом, каждый рекорд должен быть повторен к определенной версии формы. Это требование является довольно новым, таким образом, существующее приложение не было создано с этим в памяти.
Я ищу различные способы обработать это, надеясь избежать будущего технического долга. Вот некоторые опции, которые я придумал:
- Создайте новый объект, UI и набор таблиц для каждой версии. Это - очевидно, самый наивный подход.
- Продолжайте добавлять все поля к тому же объекту и Таблицам базы данных, но покажите/скройте им на основе версии формы. Это станет путаницей после нескольких изменений.
- Определения формы сборки, затем динамично создайте UI и храните данные как некоторый словарь как формат (например, JSON/XML, или возможно документ ориентировал базу данных), я думаю, что это будет слишком сложным для объема этого приложения, специально для UI.
Что другие возможности там? У кого-либо есть опыт при выполнении этого? Я ищу некоторые шаблоны разработки, чтобы помочь иметь дело со сложностью.
3 ответа
Для этого конкретного приложения мы решили рассматривать проблему так, как если бы существовала одна форма, которая постоянно растет. Из-за природы формы это показалось более естественным, чем более явное разделение. У нас будет связка год->поле для тех частей приложения, где необходимо знать, какие данные относятся к какому году.
Для пользовательского интерфейса мы будем создавать новую страницу для формы каждого года. Динамическое создание форм слишком сложно в этой ситуации.
Сначала я расскажу о ваших решениях выше, а затем дам свой ответ.
- Создание новой таблицы для каждой версии потребует нового программирования каждый год, так как вы не сможете динамически присоединяться к новым таблицу и легко включать новые столбцы . Это кажется довольно очевидным и действительно делает это плохим выбором.
- Проблемы, о которых вы упомянули при добавлении
столбцов в ту же форму,
верны. Кроме того, любая база данных, которую вы используете, имеет максимальное количество столбцов , которые она может обрабатывать, и количество байтов в строке. Это могло стать еще одним поводом для беспокойства. - Третий вариант, на мой взгляд, наиболее близок к тому, что вы хотите. Я бы не сохранил данные нового столбца в JSON / XML, если только он не используется для дублирования для увеличения скорости. Я думаю, что это ваш лучший вариант
- Единственный вариант, о котором вы не упомянули , - это сохранение всех данных в 1 поле базы данных и использование XML для {{1 }} синтаксический анализ. Этот вариант затруднит выполнение запросов и составление отчетов .
Если бы мне пришлось сделать это:
- Первая таблица имела бы ID столбцов (с начальным значением), имя, InputType, CreateDate, ExpirationDate и CssClass . Я бы назвал это tbInputs.
- Вторая таблица будет иметь 5 столбцов, ID, Input_ID (с FK на tbInputs.ID), Entry_ID (с FK на основную / исходную таблицу ) значение и CreateDate. FK к основной / исходной таблице позволит вам узнать, какие элементы были прикреплены к какой записи формы. Я бы назвал эту таблицу tbInputValues.
- Если вы не планируете иметь эту базовую таблицу, я бы использовал простую таблицу, которая отслеживает дату создания, идентификатор создателя, и form_id.
- Как только они у вас появятся, вам просто нужно будет создать динамическую форму, которая извлекает все входные данные, которые в настоящее время активны, и отображает их. Я бы поместил все динамические элементы управления в какой-то контейнер, например , поскольку он позволит вам перемещаться по ним, не зная имени каждого элемента. Затем вставьте в tbInputValues идентификатор ввода и его значение.
- Создайте форму для добавления или удаления ввода . Это означало бы, что у вас не будет много работы по техническому обслуживанию каждый год.
Я думаю, что это решение может показаться не самым красноречивым, но при правильном исполнении я думаю, что это ваше самое гибкое решение, требующее наименьшего количества технических долгов.
2ответ дан 7 December 2019 в 14:31поделиться
Я думаю, что третий подход (XML) является наиболее гибким. Простая структура XML создается очень быстро, ее можно легко версировать и проверять на соответствие XSD.
У вас будет таблица, содержащая XML в одном столбце и год / версию, к которой применяется этот XML.
Создание кода пользовательского интерфейса на основе схемы - плохая идея. Если вам не требуется тщательная проверка, вы можете выбрать простую редактируемую таблицу.
Если вам нужна настраиваемая форма каждый год, я бы рассматривал ее как своего рода гарантию работы :-) Тем не менее, важно сделать механизм управления версиями и расширения прозрачными и явными.