数据库设计 - 可选位字段
我正在构建一个数据库,用于存储问题和答案。到目前为止,有多种问题类型涉及日期时间答案、自由文本、DropDownList 以及一些链接到数据库中其他表的问题类型。我的设计问题是这样的:某些问题类型具有该类型独有的其他布尔属性。是在通用问题表中包含布尔列更好,还是为每种问题类型创建某种标志表更好?
例如,DropDownList 问题可能有一个布尔属性,用于指示在选择值“其他”时是否显示文本框,但自由文本问题对此没有用处。
谢谢堆
编辑:
我想这似乎归结为是否最好将未使用的列存储在通用问题表中以扩展每个问题类型,并使用视图将大量键返回到问题表以访问各种数据问题类型。
I'm building a database that will be used to store Questions and Answers. There are varying Question types that deal so far with a DateTime answer, Free Text, DropDownList, and some that link to other tables in the database. My design question is this: Some Question types have other boolean attributes that are unique to that type. Is it better to have the boolean column in the generic Questions table or create some sort of Flag table for each question type?
As an example, a DropDownList Question might have a boolean attribute to tell whether or not to display a TextBox when a value "Other" is selected, but a Free Text Question would have no use for this.
Thanks heaps
EDIT:
I guess it seems to be boiling down to is it better to store unused columns in a generic Questions table to extend out for each Question type and have lots of keys back to the Question table using Views to access the data for various Question types.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
从基本问题表中删除所有额外的属性,并为“问题类型”提供一个字段,并为每种问题类型提供一组表。在您的应用程序代码中,根据问题类型从特定问题类型表中检索行并使用它们。
示例:
基本问题表:
t_question
假设您有两种问题类型:
综合
或简单
。使用架构为每个表创建两个表:t_compflags
和t_simpleflags
>。现在,在基本问题表中,
QuestionType
将采用两个值:Compressive
或Simple
。基于该字段,它使用QuestionTypeLink
来引用任一表中的行。编辑:
您不能直接对这些选项卡强制执行 PK-FK 约束,您必须在应用程序代码中执行此操作。但如果您想强制执行该约束,则有一种肮脏的方法。使用两列
CompQuestionTypeLink
和SimpQuestionTypeLink
代替QuestionTypeLink
,它们允许空值并引用其他两个表。但我个人认为这是一个糟糕的设计。Strip out all the extra attributes from the base question table and have a field for the 'Question Type' and a set of tables for each question type. In your application code, based on the questions type retrieve the row from the particular question type table and use them.
An example:
Base Question Table:
t_question <QuestionID, Question, QuestionType, QuestionTypeLink>
Let's say you have two question types:
Comprehensive
orSimple
. Create two tables for each of them with schema:t_compflags <linkID, field1, field2...>
andt_simpleflags <linkID, field1, field2...>
.Now in the base question table,
QuestionType
would take two values:Comprehensive
orSimple
. Based on that field it uses theQuestionTypeLink
to refer the row in either of the tables.EDIT:
You can't directly enforce PK-FK constraint on these tabes, you have to do that in application code. But if you would like to enforce that constraint, there is a dirty way of doing it. Instead of
QuestionTypeLink
, have two columnsCompQuestionTypeLink
andSimpQuestionTypeLink
which allow nulls and references the other two tables. But I personally think this is a bad design.这完全取决于您想要进行多少标准化以及您正在讨论多少列。
如果您期望有相当多的数字,那么您应该有一个 1:1 的表关系,只是为了扩展该问题类型。像
Create Table QuestionType_DropDownList
(OtherDisplay bit,
SomethingElse bit)
这样的东西更容易阅读和查询。但它并不容易维护。不幸的是,这是一个优点/缺点的事情。
根据我的经验,我会选择这个解决方案,因为你永远不知道未来会发生什么。
This depends entirely on how much normalisation you want to do and how many columns you're talking about.
If you are expecting quite a number then you should have a 1:1 table relationship simply to extend that question type. Something like
Create Table QuestionType_DropDownList
(OtherDisplay bit,
SomethingElse bit)
This is easier to read and easier to query. But it's not easily maintainable. It is unfortunately very much a pros/cons thing.
In my experience I would pick this solution as you never know what the future may hold.
根据您拥有的组合数量,您可以将每个组合表示为其自己的类型:
这会稍微扁平化您的设计,但代价是潜在的组合爆炸。但我不知道你有多少种组合,或者将会有多少种组合。
如果 DropDownList 选项为“其他”,是否可以自动包含文本框?或者是否存在用户不必指定“其他”是什么的情况?
如果您有太多组合需要考虑,那么听起来您仍然需要在每个问题的基础上指定标志,因此在问题表中包含另一个字段来指定这些标志是有意义的。也许将它们作为纯文本,以便您可以在需要时进行扩展?就像该字段中以逗号分隔的标志列表一样?
Depending on how many combinations you have you could just express each combination as its own type:
This flattens your design a little at the expense of a potential combinatorial explosion. But I don't know how many combinations you have, or will have.
Could you include the text box automatically if you have a DropDownList choice of "Other?" Or would there be a case when the user wouldn't have to specify what "other" is?
If you have too many combinations to consider, then it still sounds like you'll need to specify the flags at a per-question basis, so it makes sense to include another field in the Questions table to specify these flags. Maybe have them as plain text so you can extend later if you need to? Like a comma-separated list of flags in that field?
我正在考虑将其作为一种可能的解决方案,对我来说似乎更加抽象,并且允许未来的扩展。
I am mulling this over as a possible solution, seems more abstracted to me and allows for the most future extension.