Ios 在核心数据中存储400000个数据用于地铁线路查找是否不同寻常？

我正在尝试制作一个地铁应用程序，它可以找到从一个车站到另一个车站的最短路径

我尝试了Dijkstra算法，每次用户选择起点站和终点站时，我都会使用几个堆样本来计算最佳路线

但我想知道是否最好将所有可能的路线存储在核心数据中，这样应用程序就不必每次计算最佳路线，而是从核心数据中获取最佳路线信息

有624个车站。和624 X 624=389376从任何车站到任何车站的现有路径

每条可能路线的信息包含如下内容：

- starting station : String
- end station : String
- stations in-between : String 
- total time it takes in seconds : Double
- number of transfers : Int
etc. 

我的主要问题是：假设我已经有389376个数据，如果我将全部400,00个数据存储在核心数据中，会不会占用太多的磁盘内存？或者只是一个小问题。

---

我尽量避免使用Dijkstra，因为考虑到转会时间、转会偏好等需要花费大量时间。

不一定。我有几个应用程序，每个磁盘上有1GB到11GB。您的使用量似乎低于1GB

如需参考，请查看您的iPhone首选项->常规->管理存储，了解其他应用的存储使用情况

---

考虑到许多用户可能只有16GB的iPhone。

< P>如果你真的想存储所有这些数据，我建议你使用SQLite代替CordDATA来正确管理你的现金数据大小。有很好的包装材料可以做这个用途

您可以将数据库的大小估计为

- starting station : String (average size about 20 bytes - one byte per char)
- end station : String (average size about 20 bytes)
- stations in-between : String  (average size about 20 bytes)
- total time it takes in seconds : Double (8 bytes)
- number of transfers : Int (4 bytes) 

---

总计：每行72字节*400 000=27,4 Mb

假设

站点：字符串

是站点名称，最好使用有序关系，而不是“中间的站点”的串联名称。应该减少一点db大小，当然可以加快它的速度。其余部分取决于您的资源。实际上，当站点列表更新时，您可以让用户从服务器下载预先计算的路由信息和/或在设备上重新计算路由。完全静态的数据库似乎不太好，因为您希望支持用户首选项。谢谢。如果核心数据使用SQLite，从来没有考虑过使用SQLite而不是核心数据的有序关系？这里有一个链接可以回答您的问题。简而言之，核心数据生成了大量上下文，如果您不想占用大量空间，可以使用SQLite。当然，您可以使用核心数据，但它的空间要大2倍左右