我最近开始使用 RavenDB。
这是关系数据库中的一个传统示例：
ID:1 类型:DEV ID:2 类型:QA
姓名：弗雷德 TYPEID：1
姓名：JACK TYPEID：2
根据我对 RavenDB 的了解，该类型将包含在员工中：
名称：FRED 类型：DEV
名称：JACK 类型：QA
那么是否需要 EmployeeType 表？
如果不是，如果您要显示员工类型的下拉列表，您会从 Employee 中选择 distinct(Type) 吗？
如果您要执行上述操作，您将如何在不输入新员工（或编辑现有员工）的情况下添加新员工类型？或者你会在某个地方的代码中保留一个列表吗？
最后，如果更改了员工类型的文本，您似乎需要更新所有员工记录。如果有 100,000 条员工记录怎么办？
我是 Raven（文档数据库）的新手，因此任何有助于我更好地掌握不同范式的见解将不胜感激。
那么是否需要 EmployeeType 表？
将有满足下一个问题的要求。此外，这种类型的参考数据可以只存储在单个文档中，而不是文档集合中。您还可以维护一个硬编码列表，一起绕过数据库。
如果不是，如果您要显示员工类型的下拉列表，您会从 Employee 中选择 distinct(Type) 吗？
否。从员工类型文档中选择。从员工表中选择不同的选项会告诉您记录的员工类型，而不是可用的员工类型。
最后，如果更改了员工类型的文本，您似乎需要更新所有员工记录。如果有 100,000 条员工记录怎么办？
您正面临关系数据库和文档数据库之间的有效权衡。你有几个选择。您可以通过指向员工类型文档集合的 ID 从员工文档中引用员工类型。这样，您可以在一处更改员工类型名称。但是，权衡是 RavenDB 将需要包含（连接）这两个文档以返回具有类型的员工。另一种方法是避免使用员工类型 ID 并将类型直接存储在员工文档中，当需要更改名称时，您将在所有文档中运行更新。从 RavenDB 文档看这里。