我有一个应用程序可以让用户创建不同的表单(调查)然后填写它们。 (因此它可以替代纸张)。
这是我在应用中使用的当前模型:
Table 1)
+-------------------------+
| SURVEYS TABLE |
+----+------+-------------+
| ID | name | description |
+----+------+-------------+
Table 2)
+-----------------------------------+
| $[name_of_the_survey] |
+----+-------+------+-------+-------+
| ID | field | type | value | items |
+----+-------+------+-------+-------+
Table 3)
+--------------------------------------+
| $[name_of_the_survey] _records |
+----+---------------------------------+
| ID | columns specific to each survey |
+----+---------------------------------+
基本上,当用户创建调查时,程序会在调查表中插入一条记录,然后创建 2 个表:
表(2)为表单的字段 表(3) 为将要存储的记录,其中的列对应于表(2) 的行。
它可以工作,但有一些限制。例如,当您向表 (2) 添加一个字段时,它必须读取表 (3) 的内容,将其保存到一个虚拟表中,删除之前的表 (3) 并创建一个新表。当 table(3) 有很多记录时,这可能是一个性能问题。
所以我的问题是...是否有更好的数据库设计?
最佳答案
为每个调查使用单独的表格几乎会使数据库的使用无效。您也可以将结果存储在文件中。
但是,您确实需要三个表:调查定义、调查问题和调查答案。它可能看起来像这样......
Surveys:
ID; name; description
Questions:
ID; text; surveyID
Answers:
ID; answer; questionID
您可以从那里增加复杂性来处理枚举的答案...
Surveys:
ID; name; description
Questions:
ID; text; surveyID
Choices:
ID; choice; questionID
Answers:
ID; choiceID
您使用每个表之间的关系聚合到下一个最高级别,从而允许您从任何问题、调查或您选择添加的任何模型的任何其他属性中获得结果,而无需尝试抽象出您选择的来源声明。这还允许您稍后在将每个用户或调查组织的答案添加到您的模式后汇总它们。如果每个调查都有自己的表结构,那么随着应用程序的增长,跨调查汇总数据将变得非常不切实际。
关于android - 什么是最好的 : 1 table per record or 1 table with all records linked with foreign keys?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/4258517/