表数未知的SQLite图ERD

我有一个GPS android应用程序，我已经做了。它使用SD卡上的SQLite数据库存储位置数据。我正在尝试为数据库创建一个ERD（实体-关系图）。这就是我遇到问题的地方。数据库有一个轨道主表和一个航路点组主表（一个或多个航路点的集合）。这些表中没有位置数据，只有轨道或航路点组的名称、开始/停止时间和日期以及uid。对于这些表中的每一行，将创建一个包含纬度和经度信息的新表。在子表中，每行是一个点或顶点。子表名称是“主”表的uid加上“t_uu”或“w_u”表示轨迹或航路点。这就是我用以下方法得出的结论：

（对不起，我没有10个代表点来发布图片，哈哈）

我认为表之间的组合链接是正确的，因为只有在主表中有一行时，子表才存在。如果删除了主行，则相应的子表也将被删除。但是如何显示主表中的每一行都有一个子表呢？这也有点奇怪，因为子表中不需要FK，因为表名提供了这个函数

---

我不认为我想在这么晚的时候改变我的数据库结构，因为这个应用程序很快就会被发送出去进行测试，但我会对这个问题的其他（高级）数据库设计感兴趣。

在关系数据库中，数据是链接的。但是，在数据库中，不仅链接了数据，还链接了具有表名的数据。因此，您将内容与结构混合在一起

据我所知，您不能在ERD中显示这一点。您也无法在dbms中正确实现这一点（这样您的dbms就可以了解结构并帮助您进行适当的约束）

您没有正确使用RDBMS。所以，尽管时间已经很晚了：如果我是你的话，我会把它转换成一个合适的关系数据库模型

---

编辑：一个合适的关系模型只是在一列中只有一个track_detail表，该表的track id在列中，而不是在其名称中。与主航路点id相同的航路点详细信息。实际上没有大的变化。

感谢Thorsten的反馈。好吧，只是为了确定我明白你的意思。我应该有一个包含所有轨迹顶点的表（对于所有轨迹），然后FK将是“主”轨迹的uid。是的，我看得出来。拥有一个可能有几十万条记录的大型表，而不是每个都有几千条记录的多个表，是否存在性能问题？此外，我不确定我是否看到了我现在拥有它的不利一面。我猜风险在于，如果应用程序将来需要将自身之外的数据传递给“真正的”RDBMS系统。这是一个真正的风险，因为他们确实有一个Oracle数据库和一个ESRI SDE……我不认为有几十万个记录那么大。这就是dbms的全部内容：尽快找到合适的记录。通过应用FK约束和索引，dbms可以轻松找到获取数据的最佳方法。这不应该是个问题。至于缺点：想想你会如何选择最相关点的轨迹。或最接近当前位置的轨迹。正如我所描述的，使用关系数据库很容易做到这一点，但在您的模型中仅使用SQL是不可能的。好的，谢谢您对我进行整理。我将按照你的建议考虑改变它。