так потеряли в разработке этих таблиц!

Question

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

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

Пользователь может вводить данные в свою форму и запрашивать данные тоже.

форму можно редактировать после создания и использования (добавить / удалить поля из нее).

форма может иметь такие поля, как: маленькое текстовое поле, большое текстовое поле, один список, флажок, раскрывающееся меню ....

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

Я хочу спроектировать свои таблицы так, чтобы, если я решу обновить свое приложение позже и добавить новый тип, мне не нужно будет изменять свою схему! например, если сначала я разрешил пользователю использовать только текстовые поля и выпадающие меню, то позже я обновляю свое приложение и добавляю новый тип: «флажки»! я хочу, чтобы пользователь мог редактировать свою форму и добавлять к ней флажки без необходимости изменения схемы.

поэтому я подумал (и, пожалуйста, помогите мне здесь) иметь:

1 - каждое ПОЛЕ имеет (ID-Name-Position-value) 2- У каждого ПОЛЯ есть ровно один ТИП 3- каждый ТИП может быть одним из них (строка - числовая - дата - двоичная - короткая) 4 - каждое ПОЛЕ может иметь один или несколько элементов 5 - если в ПОЛЕ есть несколько предметов, то наверняка у него есть «один выбранный предмет»

(4 и 5 - для полей раскрывающегося меню).

, поэтому я получаю 3 таблицы:

ТАБЛИЦА ПОЛЯ, таблица TYPE и таблицы MUTLIPLE ITEMS.

это правильно? что если я захочу добавить новое "поле" ... это будет сделано? пожалуйста, помогите, я действительно новичок в этом! я тяну меня за волосы с тех пор, и я не могу это исправить !!

Answer 1

На этот вопрос сложно ответить, потому что требования:

текстовые поля будут сгруппированы вместе в одной таблице раскрывающиеся списки в другой стол ...

и

... если я решу обновить мой приложение позже и добавить новый типа, мне не нужно изменять мою схему ..

противоречат друг другу.

Итак, если вы не хотите изменять схему, взгляните на на этот вопрос / ответ .

Если вы согласитесь немного изменить схему, взгляните на модель. В этой модели вам нужно будет добавить новую таблицу для каждого нового типа элемента, но вам не придется изменять какие-либо существующие таблицы. Поместите все общие поля в таблицу Element и только определенные поля в TextBox, List, CheckBox, ...

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

Answer 2

Вот как я бы это описал, чтобы избежать избыточности данных:

formTable
---------
id             varchar(36)
name           varchar(36)
creationDate   date
lastUpdate     date
isActivated    boolean
...
...

componentTable
--------------
id     varchar(36)
name   varchar(36)
...
...
...

formComponentTable
------------------
form_id       varchar(36)
component_id  varchar(36)


metadataTitleTable
-----------------
id       varchar(36)
name     varchar(36)

metadataValueTable
------------------
id       varchar(36)
name     varchar(36)

metadataTable
-------------
metadata_id varchar(36)
title_id    varchar(36)
value_id    varchar(36)

metadataComponentTable
----------------------
component_id varchar(36)
metadata_id  varchar(36)

Теперь позвольте мне объяснить вам, как я это вижу.

У вас есть форма, которую вы вставляете в formTable, со всеми необходимыми данными.Даты, владелец и т. Д. ...

Форма состоит из нескольких компонентов.formComponentTable свяжет форму с различными составляющими, составляющими ее.Тогда metedata*Table позволит вам описать все ваши компоненты.

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

Ну, я думаю, это должно стать хорошим началом для вас, чтобы начать думать о своем дизайне.

Если вам нужна дополнительная помощь, не стесняйтесь добавлять комментарии,

Редактировать: в этом случае контент может рассматриваться как метаданные.Таким образом, у вас будет набор в metadataTitleTable, который будет content, а затем набор в metadataValueTable фактическом content, тогда вам просто нужно связать все вместе.