这是我的表格：
跟踪：
ID (PK,bigint,not null) DeploymentID (FK,int,not null) AppCode (int,not null)
部署：
DeploymentID (PK,not null) DeploymentVersion (varchar(10),not null) DeploymentName (nvarchar(max),not null)
应用：
AppID (PK,not null) AppName (nvarchar(max),not null)
目前我的表中有这些行：
跟踪：
ID: 1,DeploymentID: 1,AppCode: 1 ID: 2,AppCode: 2 ID: 3,AppCode: 3 ID: 3,DeploymentID: 2,AppCode: 1
部署：
DeploymentID: 1,DeploymentVersion: 1.0,DeploymentName: "Test1" DeploymentID: 2,DeploymentName: "Test2"
应用：
AppID: 1,AppName: "Test1" AppID: 2,AppName: "Test2" AppID: 3,AppName: "Test3"
我的问题是：我该如何构建我的Nosql文档模型？
看起来应该是这样的：
trace/1
{
"Deployment": [ { "DeploymentVersion": "1.0","DeploymentName": "Test1" } ],"Application": "Test1"
}
trace/2
{
"Deployment": [ { "DeploymentVersion": "1.0","Application": "Test2"
}
trace/3
{
"Deployment": [ { "DeploymentVersion": "1.0","Application": "Test3"
}
trace/4
{
"Deployment": [ { "DeploymentVersion": "1.0","DeploymentName": "Test2" } ],"Application": "Test1"
}
如果部署1发生变化怎么办？我应该查看每个文档并更改数据吗？
什么时候应该在Nosql中使用引用？
解决方法
因此,为了回答您的问题,我们真正需要知道的是您打算如何使用这些数据.例如,显示按时间排序的所有跟踪与显示与特定部署或应用程序关联的跟踪明显不同.这些要求中的每一个都将规定不同的设计,并支持它们.
这本身对你来说可能是有用的信息(？),但我怀疑你想要更具体的答案:)所以请在你的预期用途上添加一些额外的细节.
在决定策略时,有一些“做”和“不做”：
DO：针对常见用例进行优化.通常有20/80的细分,其中20％的UX驱动80％的负载 – 网络应用的主页/登陆页面是一个典型的例子.首要任务是确保这些尽可能高效.确保您的数据模型允许A)在单个IO请求中加载它们或B)是缓存友好的
不要：不要陷入可怕的“N 1”陷阱.当您的数据模型强制您进行N次调用以加载N个实体时,通常会先执行额外调用以获取N个ID列表,从而出现此模式.这是一个杀手,特别是与#3一起……
DO：始终限制(通过UX)您愿意获取的数据量.如果用户有3729条评论,您显然不会立即获取所有评论.即使从数据库的角度看它是可行的,用户体验也会很糟糕.这就是搜索引擎使用“未来20个结果”范例的原因.因此,您可以(例如)将数据库结构与UX对齐,并将注释保存为20个块.然后每个页面刷新涉及单个DB get.
DO：平衡读写要求.某些类型的系统读取很重,您可以假设每次写入都会有很多读取(StackOverflow就是一个很好的例子).因此,为了获得读取性能的好处,使写入更加昂贵是有意义的.例如,数据非规范化和复制.其他系统均衡平衡甚至写重,需要其他方法
DO：使用TIME的维度. Twitter是一个典型的例子：99.99％的推文在第一小时/每天/每周/之后永远不会被访问.这将在您的数据模式中打开各种有趣的优化可能性.
这只是冰山一角.我建议稍微阅读基于列的Nosql系统(例如Cassandra)