在设计这些桌子时如此迷失!

发布于 2024-10-07 13:20:57 字数 702 浏览 1 评论 0原文

我之前发布了这个问题,但没有得到任何答案!我会尝试重新措辞并使其更清楚,希望得到有用的建议。

我想构建一个允许用户构建自己的表单的应用程序。

用户可以在其表单中输入数据并查询数据。

表单在创建和使用后可以进行编辑(添加/删除字段)。

表单可以包含以下字段:小文本框、大文本框、单个列表、复选框、下拉菜单...

我想根据字段的类型将字段分组到表中...(文本框将分组在一起在一个表中,下拉列表在另一个表中 等等一)。

我想设计我的表,这样如果我决定稍后升级我的应用程序并添加新类型,我就不必更改我的架构!例如,如果一开始我只允许用户使用文本框和下拉菜单,那么后来,我升级我的应用程序并添加一个新类型:“复选框”!我希望用户能够编辑其表单并向其添加复选框,而无需更改架构。

所以我在想(请帮助我):

1-每个字段都有(ID-名称-位置-值) 2-每个字段只有一种类型 3-每个类型可以是其中之一(字符串-数字-日期-二进制-短) 4-每个字段可以有一个或多个项目 5-如果字段有多个项目,那么它肯定有“一个选定的项目”

(4 和 5 用于覆盖下拉菜单字段)。

所以我最终得到了 3 个表:

FIELD TABLE、TYPE 表和 MUTLIPLE ITEMS 表。

这是正确的吗?如果我想添加一个新的“字段”怎么办?这可以吗?请帮忙,我对此真的很陌生!我一直在拉扯我的头发,但我无法解决这个问题!

I posted this question earlier but i didn't get any answer ! i will try to rephrase it and make it more clear hoping to get helpful advice.

I want to build an application that allows a user to build its own form(s).

A user can input data into its form and query the data too.

the form can be edited after being created and used ( add/remove fields from it ).

the form can have fields like: small text box, big text box , single list, check box, drop down menu ....

i want to group the fields into tables according to their types... (text boxes will be grouped together in one table, drop down lists in another table
and so one ) .

I want to design my tables so that if i decide to upgrade my application later on and add a new type ,i wont have to ALTER my schema ! for example, if at first i only allowed the user to use text boxes and dropdown menus, then later on, i upgrade my application and add a new type : the "check boxes" ! i want the user to be able to edit its form and add checkboxes to it without having to change the schema .

so i was thinking ( and please help me out here ) to have:

1- each FIELD has ( ID-Name-Position- value)
2- each FIELD has exactly one TYPE
3- each TYPE can be one of these ( string - numeric - date - binary - short )
4- each FIELD can have one or more multiple items
5- if a FIELD has multiple items, then for sure it has "one selected items"

(4 and 5 are to cover the dropdown menu fields).

so i end up with 3 tables :

FIELD TABLE and the TYPE table and the MUTLIPLE ITEMS tables.

is this correct ? what if i want to add a new "field"..would this do it ? please help, im really new at this!! ive been tugging at my hair since forever and i cant get to fix this !!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

滥情稳全场 2024-10-14 13:20:57

这个问题有点难以回答,因为要求:

文本框将被分组在一起
在一张表中,下拉列表位于
另一张桌子...

...如果我决定升级我的
稍后应用并添加新的
输入,我不必更改我的架构..

有冲突。

因此,如果您不想更改架构,请查看这个问题/回答

如果您愿意稍微修改架构,请查看模型。在此模型中,您必须为每个新元素类型添加一个新表,但不必修改任何现有表。
将所有常见字段放入 Element 表中,仅将特定字段放入 TextBox、List、CheckBox、...

alt text

此外,表单元素大多是标准的——您可以立即列出它们并简单地创建所有表格,即使应用程序当前不支持它们。这样您就很少需要修改架构。

This one is a bit hard to answer because the requirements:

text boxes will be grouped together
in one table, drop down lists in
another table ...

and

... if i decide to upgrade my
application later on and add a new
type ,i wont have to ALTER my schema ..

are conflicting.

So, if you do not want to alter the schema, take a look at this question/answer.

If you would accept to modify the schema a bit, take a look the the model. In this model you would have to add a new table for each new element-type, but would not have to modify any existing tables.
Place all common fields into the Element table, and only specific ones into TextBox, List, CheckBox, ...

alt text

Furthermore, form elements are mostly standard -- you could list them all right now and simply create all tables even if the application currently does not support them. This way you would rarely need to modify the schema.

醉酒的小男人 2024-10-14 13:20:57

这就是我将如何设计它以避免数据冗余:

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 中设置一个内容,然后在 metadataValueTable 中设置实际的内容 > 然后你只需要把所有东西绑定在一起。

That how I would desgin it to avoid data redundancy :

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)

Now let me explain you the way I see it.

You have a form that you insert in the formTable, with all the datas you need. Dates, owner, etc...

A form is composed of a multiples components. The formComponentTable will bind the form with the various components that composes it. Then the metedata*Table will let you describe all of your components.

I did not understand why did you want to create a table for every kind of components. Why don't you just add a column that would define which type is it. Do you get me ?

Well I think that should be a good start for you to start thinking your design.

If you need more help don't hesitate to add comments,

Edit : content can -in this case- be considerated as a metadata. So you would have a set in the metadataTitleTable that would be content and then a set in the metadataValueTable the actual content then you just have to bind everything together.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文