数据库设计
我正在创建一个数据库,记录多个表单的详细信息,每个表单都有一个状态和修订。我想创建一个表来保存所有表单的所有修订和状态数据,但是我对设计以及如何定义表单表与第一个修订和状态表之间的关系有点困惑。
我的表格如下。 为了简单起见,我缩写了表格
tasks
---------
pk int id
briefs
---------
pk int id
Revisions
---------
fk formId
int status
我想将任务和摘要表链接到修订表,但显然会与父表的 pk 发生冲突。是像查找表一样使用修订表并将修订表的主键存储在任务和摘要表中的最佳选择。
提前致谢
im creating a database that records details from multiple forms and each form has a status and a revision. I want to create one table that holds all the revision and status data for all the forms however im a little stuck with the design and how i can define the relationships between the forms tables and the 1 revision and status table.
The tables i have are as follows. Ive abbreviated the tables for simplicity
tasks
---------
pk int id
briefs
---------
pk int id
Revisions
---------
fk formId
int status
I want to link the tasks and the briefs table to the revisions table but obviously there will be a conflict with the pk's of the parent tables. Is the best option to use the revisions table like a look up table and store the primary key of the revisions table in the tasks and briefs table.
Thanks in advance
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
选项 1:
创建表单表,它是表单 ID 的中心来源。当插入到任务/简报/等中时(我假设可能还有更多),您首先插入到表单表中,然后使用该 ID 作为任务或简报中的 PK/FK。
然后你在Revisions中有FormID,只需引用Forms中的FormID即可。
您可能希望在 Forms 表中记录表单类型,并且可能会强制执行,如果您在 Forms 中插入了“1,Task”,则唯一可以插入 1 的表是 Tasks 表。有一些方法可以做到这一点。
您可能还想将其中一些事实隐藏在视图/触发器后面(因此您只需插入到任务中,然后在幕后插入到表单中,等等)。
选项 2:
在修订表中为每个表创建一列。添加一个约束,使这些列中的某一列不为空。这确实允许您使用更具体的外键约束(与选项 1 不同,在选项 1 中,仅仅因为 Forms 中有一个 Form ("1,Task"),您就不能保证 Tasks 表中会有一行)。但如果您要添加新的表单类型,则必须向修订添加更多列。
还有其他一些选择,但我想到的就是这两个。
Option 1:
Create a Forms table, that is the central source of Form IDs. When inserting into Tasks/Briefs/etc (I assume there may be many more), you first insert into the Forms table, then use that ID as a PK/FK in Tasks or Briefs.
Then you have FormID in Revisions just reference the FormID in Forms.
You'd probably want to record the form type in the Forms table, and possibly enforce that if you've inserted say "1,Task" into Forms, that the only table you can insert 1 into is the Tasks table. There are ways to do that.
You might also want to hide some of these facts behind views/triggers (so you just insert into Tasks, and behind the scenes it does the insert into Forms, etc).
Option 2:
Create one column per table in the Revisions table. Add a constraint such that exactly one of these columns is not null. This does allow you to use more specific foreign key constraints (unlike option 1, where just because there's a Form ("1,Task") in Forms, you couldn't guarantee there would be a row in the Tasks table). But if you're adding new form types, you have to add more columns to Revisions.
There are some other options, but these are the two that spring to mind.
如果任务和摘要中只有 id 而没有其他列,或者列相同,则可以在两个表中执行此操作。
You could do this in two tables, if tasks and briefs only have the id in them and no other columns, or if the columns are identical.
听起来您可以将任务和摘要视为超类型“表单”的子类型。 (我在关系数据库设计意义上使用超类型和子类型,而不是在面向对象编程意义上。)
完成此操作后,您可以创建一个修订表引用“forms”中的主键。
这种特殊的结构假设
修订号、
如果任务修订与简要修订的含义不同,那么您需要一个用于任务修订的表,另一个用于简要修订的表。它们的主键不会引用超类型表“forms”;他们会引用子类型表“任务”和“简介”。
It sounds like you can treat tasks and briefs as subtypes of the supertype "forms". (I'm using supertype and subtype in their relational database design sense, not in their object-oriented programming sense.)
Having done that, you can create a table of revisions that references the primary key in "forms".
This particular structure assumes that
revision number, and
If task revisions don't mean the same thing as brief revisions, then you need one table for task revisions, and another table for brief revisions. Their primary keys wouldn't reference the supertype table "forms"; they would reference the subtype tables "tasks" and "briefs" instead.