更新：关系（或 NoSQL）数据库设计
Rui*_*ito 5 mysql schema database-design relational-theory
（用更多细节更新了这个问题。决定使用关系数据库，并希望对其设计发表一些评论）
该数据库保存了造船的装配指令数据，稍后在增强现实 Android 应用程序中使用。应用程序要求服务器 (Node.JS) 提供必要的文件。
简单的说：工作包包含几个零件，必须安装，每个部分有文件所需的应用程序所需。
- 工作包依赖于其他工作包（WD_Dependencies），上图中S1依赖于1和2；
- 工人可以被分配一个特定的工作包，如果没有，返回的工作包是Type和Department之间匹配的组合。
更新：
（在新选项卡中打开以获得更好的查看效果）
数据库在项目蓝图和该蓝图的具体执行之间“划分”。这也允许多次执行同一蓝图。
问题：
- 这是一个好的设计吗？划分蓝图和项目？
- 递归查找工作包的所有依赖项的高效 SQL 查询？
- 您是否发现关系或冗余有任何问题？
- 欢迎任何意见或帮助。
我知道这可能是一个广泛的/意见问题，但我对这种规模的数据库没有经验，希望得到帮助。
这两个选项中哪一个最好？
关系设计显然优于 NoSQL 示例中使用的分层设计。使用关系原则设计的数据库模式并不支持一种访问路径而不是另一种访问路径。每个表代表一个现实世界的实体类型，并且通过使用任意复杂度的关系代数查询，可以构建不仅可以回答当前的数据问题，还可以回答您想到的尚未设想的任何未来问题。分层模式对数据强加单一结构 - 在这种情况下，工作包包含其他工作包、工作人员、部件和文件。如果您想提出与此单一视图不相符的数据问题，即使不是不可能，也会困难得多。此外，关系模型包括一个数据完整性组件，以确保数据与向其声明的接近现实世界的规则一致，而使用分层或网络模型的系统（如 NoSQL 系统）不提供这些。
工作包是否应该引用上述工作包，还是相反更好？
实现此目的的最佳方法是创建一个新表来表示父工作包和从属工作包之间的链接，同时让工作包表表示工作包本身，而不管依赖关系如何。此设计不会将依赖于其他工作包的工作包与不依赖于其他工作包的工作包混合在一起。关系方法的一个关键优点是，具有一组运算符（关系表和关系代数）的单个结构可以轻松表示层次结构或网络。网络 DBMS 需要两种类型 - 节点和链路 - 以及两组不同的运算符，因此复杂性增加了一倍。分层 DBMS 根本无法正确表示网络。这是当今可用的 NoSQL 系统只能解决一小部分用例的关键原因。 Fabian Pascal的书《数据库管理中的实际问题》第 7 章对使用 SQL 的数据层次结构进行了精彩概述，我强烈推荐它。
将会有大量的读取，但写入会少得多。
关系方法的另一个好处是可以在很大程度上在物理级别上管理系统的性能，而不会影响应用程序用于处理数据的逻辑数据库模式。使用关系方法，您可以首先关注正确的逻辑模式，然后在大多数情况下让 DBA 实施正确的物理设计和基础架构，以最好地支持读取繁重的工作负载。在导航系统中情况并非如此，程序员必须直接在程序中指定访问路径。