数据库设计:使用映射表或直接在表中包含数据

Question

我正在编写一个项目管理Web应用程序,仅供练习.基本思想是用户可以将项目添加到应用程序,然后通过界面管理与项目相关的任务和约会.我目前正在设计数据库,我想知道最佳实践将在这里指示.

到目前为止我有4张桌子:

+----------+   +-------------+   +--------------+   +-------------+
|Users     |   |Projects     |   |Tasks         |   |Appointments |
+----------+   +-------------+   +--------------+   +-------------+
|id        |   |id           |   |id            |   |id           |
|username  |   |project_name |   |task_name     |   |appt_name    |
|fname     |   |project_desc |   |task_details  |   |appt_details |
|sname     |   |             |   |task_deadline |   |appt_date    |
+----------+   +-------------+   +--------------+   +-------------+

我将基本关系视为:

• 一个user可以有很多projects,tasks和appointments.
• 一个project可以有很多users,tasks和appointments.
• 一个task可以有很多users,但只能与一个相关联project.A task不能与a相关联appointment.
• 规则tasks也适用于appointments.

我的问题是:何时适合使用映射表,何时适合将数据直接包含在关联表中？我的例子是:

• 为每个用户 - 项目/任务/设备都有一个映射表,因为每种类型可以有很多用户,每个用户每种类型都有很多用户
• 在任务和约会表中包括一个project_id字段,可用于将任务和约会与项目相关联,从而将该项目的用户关联起来.

这是正确的方法还是有更好的解决方案？我对数据库设计还很陌生,所以我真的很感激一些建设性的批评

Answer 1

我目前正在设计数据库,我想知道最佳实践将在这里指示

最佳实践规定必须将数据建模为数据,而不考虑使用或应用程序.不考虑平台,但这些天世界是颠倒和倒退,首先选择平台.

建模意味着您在考虑第二个实体之前首先识别并考虑实体(例如"映射").

没有选择

我的问题是:什么时候适合使用映射表

这是正常的方法.

• 正确
• 理论上成立
• 允许用户期望数据库具有的所有功能和能力
  • 例如.聚合,单个或多个项目(列表的子集)搜索非常快,等等
• 易于扩展
• 防止可预防的错误
• 在天堂为你提供可以兑现的筹码.

何时适合将数据直接包含在关联表中？

决不.这将在单个列中创建以逗号分隔的列表.

• 不正确
• 没有理论基础
• 打破第一范式
• 亲爱的人(他们不仅不知道规则,他们不知道什么时候他们打破了他们所知道的一些规则)
• 数据库的功能和功能无法使用
  • 例如.搜索,确定特定用户是否正在处理项目将导致表扫描
• 结果不是数据库,它是一个记录文件系统
• 难以扩大
• 你将花费一半的时间来解决可预防的错误,而另一半则考虑如何在不让任何人注意的情况下更换它
• 保证你在地狱,六级,欺诈和欺骗工人的工资,低于谋杀一级,一级高于悲观者和战争贩子的特定地方

为每个用户 - 项目/任务/设备都有一个映射表,因为每种类型可以有很多用户,每个用户每种类型都有很多用户

一般来说,是的.但目前尚不清楚."类型"戒指响铃,听起来你打算有一张桌子可以支持所有可能性; 可空的外键; 等.请参阅上面的"从不".

只有那些需要它的表对之间应该有一个关联表(不是"映射"),而不是在每种可能性之间.并且每个这样的表仅涉及一个离散对("链接","映射","连接").

这将在标准化完成后解决,接下来......

考虑

这个要求听起来有点可疑.我不接受这些表格都是孤立的,零碎的事实.考虑:

• 首先,任务可能是Project的一个孩子(你暗示过,这样的依赖应该是明确的).同样,约会应该是项目的孩子.与此同时,除了项目的上下文之外,任务不能存在.同样适用于约会.

• 然后,您必须评估用户是否应与项目相关(如要求中所示).在我看来,一个用户被分配给一个任务(因此与项目相关,因为任务属于一个项目),而不是项目中的所有任务.同样适用于User :: Appointment.

• 如果用户与项目(而不是特定任务)相关,则根据要求,它似乎过于笼统.特别是如果约会应用项目,因此应用于分配给项目的所有用户.

• 所以在我看来,到目前为止收到的信息,以及我的建议(尚未确认,因此这是一个薄冰),约会是在较低级别,任务级别,并可能适用于所有用户分配给任务.

• 在项目级别可能存在第二种类型的约会,其适用于分配给项目中的所有任务的所有用户的不同集合.

• 只要我的上述建议是正确的,特别是用户被分配到任务,如果在任务级别进行约会,它适用于分配给该任务的所有用户,那么根本没有关联("映射")表.

• ID无法提供行唯一性.如何确保行唯一性,如关系数据库所要求的那样？

正如您所看到的,在模型的第一个草稿中感知到的每个表上标记ID列会阻止数据建模练习.你需要10到12个草稿.在第五个左右,您将分配密钥.在9或10时,您将为需要它们的几个表(如果有)分配ID.

首先分配ID可以保证RFS中的第一个草稿实现,这意味着没有数据库完整性,没有数据库功能.

考虑,确认/凹陷,讨论等

这是一个用作讨论平台的图表.请使用它底部的链接,并熟悉符号,以适合您认为合适的任何级别.

项目管理ERD•第二稿