Обработка пользовательских пользовательских полей с возможностью увеличения и уменьшения

Question

Этот вопрос много о том, как это сделать, идея и т. Д.

У меня есть ситуация, когда пользователь может создать столько пользовательских полей, сколько он может, типа Number, Text или Date, и использовать это для создания формы. Мне нужно сделать / спроектировать некоторую табличную модель, которая может обрабатывать и хранить значение, чтобы можно было выполнить запрос по этим значениям после сохранения.

Ранее я жестко закодировал формат для 25 пользовательских полей (UDF). Я создаю таблицу с 25 столбцами с типами 10 Number, 10 Text и 5 Date и сохраняю в ней метку, если пользователь использует какое-либо поле. Затем сопоставьте его с другой таблицей, имеющей тот же формат, и сохраните значение. Сопоставление выполняется для того, чтобы узнать, какое поле имеет какую метку, но я надеюсь, что это неэффективный способ.

Любое предложение будет оценено.

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

например. скажем, пользователь создал 10 числовых полей даты 10 и 10 текстовых полей, используя первые 5 в каждом для создания form1, и все 10 для создания form2 теперь сохранили данные.

Мои мысли об этом:

Создайте таблицу1 с [id, name (как UDF_xxx, где xxx - тип данных), UserLabel]

table2 для отображения формы и table1 [id (f_key table1_id), F_id (id формы)]

и создайте 1 таблицу для каждого типа данных как [id (f_key of table1), F_id (номер формы), R_id (идентификатор строки для данных, будет одинаковым для всех типов данных), значение]

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

Answer 1

Чего вы хотите достичь?Перестановка таблиц для каждой формы или каждый набор данных может состоять из разных наборов?

Мне на ум приходят две возможности:

1. Создать таблицу, которая описывает одно поле набора данных,т. е. ключом может быть идентификатор набора данных + идентификатор поля, а дополнительные столбцы могут содержать значение, хранящееся в виде строки, и тип этого значения (т. е. число, строка, логическое значение и т. д.).
   
   Таким образом, каждый набор данных может быть разным, но после чтения набора данных и его сохранения в объекте вы можете создать соответствующие типы значений (Integer, Double, String, Boolean и т. Д.)

2. Создайте таблицу для каждой формы, используя некоторые соглашения Naimg.При изменении макета формы выполните инструкции ALTER TABLE, чтобы добавить, удалить, переименовать столбцы или изменить их тип.Когда пользователь изменяет тип столбца или удаляет его, вам может потребоваться либо отрицать это, если значения не равны NULL, либо по крайней мере спросить пользователя, хочет ли он отбросить значения, которые не соответствуют новым требованиям.

Редактировать: пример для подхода 1

Таблица UDF // описывает доступные поля
--------
id (PK)
user_id (FK)
тип
имя

Таблица FORM // описывает общие атрибуты формы
--------
id (PK)
user_id (FK)
name
description

Таблица FORM_LAYOUT // описывает макет поля формы
--------
form_id (FK)
udf_id (FK)
отображение // отображение информации, такой как индекс столбца, имя поля формы и т. Д.

Таблица DATASET_ENTRY // описывает одну запись набора данных, т.е. значениеодин UDF в
--------
id (PK)
row_id
form_id (FK)
udf_id (FK)
значение

Выбор содержимого для конкретной формызатем можно сделать так:
SELECT e.value, f.type, l.mapping from DATASET_ENTRY e
JOIN UDF f ON e.udf_id = f.id
JOIN FORM_LAYOUT l ON e.form_id = l.form_id AND e.udf_id = l.udf_id
WHERE e.row_id = ? AND e.form_id = ?

Answer 2

Есть два подхода, которые я использовал.

1. XML: Чтобы создать динамический атрибут пользователя, вы можете использовать XML.Этот XML будет храниться в столбце clob - скажем, user_attributes.Сохраните все пользовательские данные в паре ключ-значение XML с типом в качестве атрибута или другого поля.Это даст вам максимальную свободу.Вы можете использовать XOM или любой другой API объектной модели XML для отображения или обработки данных.Типичный узел будет выглядеть так:

   <userdata>
     ...
     ...
     <datanode>
       <key type="Date">User Birth</key>
       <value>1994-02-25</value>
     </datanode>
     ...
   </userdata>
   

2. Attribute-AttributeValue Это то же самое, что и выше, но с использованием таблиц.Что вы делаете, вы создаете таблицу - attributes с FK как user_id, другая таблица attribute_values с FK как attribute_id.attributes содержит несколько имен полей и типов для каждого user, а attribute_values содержит values этих атрибутов.в общем,

   users
     user_id
   
   attributes
     attr_id
     user_id (FK)
     attr_type
     attr_name
   
   attribute_values
     attr_val_id
     attr_id (FK)
     attr_val
   

Если вы видите в обоих подходах, вы не ограничены количеством или типом данных, которые у вас есть.Но есть и обратная сторона этого разбора.В любом случае вам придется выполнить небольшой объем обработки, чтобы отобразить или проанализировать данные.

Лучший из двух миров (с жесткой структурой столбцов по сравнению с полностью динамическими данными) заключается в том, чтобыusers таблица с обязательными столбцами (например, имя пользователя, возраст, пол, адрес и т. д.) и пользовательскими данными (например, любимым домашним животным и т. д.) в формате XML или attribute-attribute_value.

Answer 3

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

create table Fields(
  fieldid int not null,
  fieldname text not null,
  fieldtype int not null
);

create table FieldDate
(
   ValueId int not null,
   fieldid int not null,
   value date
);

create table FieldNumber
(
   ValueId int not null,
   fieldid int not null,
   value number
);

..

Другая возможность - использовать ALTER TABLE для создания пользовательских полей. Если ваше приложение имеет права на выполнение этой команды, а настраиваемые поля меняются очень редко, я выбрал бы этот вариант.