在 Core Data 中存储 400,000 条数据用于地铁路线查找是不是异常？

Posted 2023-03-11

【中文标题】在 Core Data 中存储 400,000 条数据用于地铁路线查找是不是异常？

【英文标题】：Is storing 400,000 data in Core Data for subway route-finding unusual?在 Core Data 中存储 400,000 条数据用于地铁路线查找是否异常？

【发布时间】：2015-06-24 13:44:28

【问题描述】：

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

我尝试了使用多个堆样本的 Dijkstra 算法来实际计算用户每次选择起点站和终点站时的最佳路线。

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

有 624 个车站。和 624 X 624 = 389,376 条从任何站点到任何站点的现有路径。

每个可能路线的信息将包含以下内容：

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

我的主要问题是：假设我已经有 389,376 个数据，如果我将所有 400,00 个数据都存储在 Core Data 中会占用太多磁盘内存吗？还是只是一个小问题。

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

【问题讨论】：

假设station : String 是站名，使用有序关系而不是“中间站”的串联名称可能是个好主意。应该稍微减小 db 大小，当然可以加快速度。其余的实际上取决于您的资源，您可以让用户从您的服务器下载预先计算的路线信息和/或在站点列表更新时重新计算设备上的路线。完全静态的数据库似乎不如你想支持用户偏好那么好。

谢谢。从没想过有序关系

【参考方案1】：

如果您真的想存储所有这些数据，我建议您使用 SQLite 而不是 CoreData 来正确管理您兑现的数据大小。为此目的有很好的包装 https://github.com/ccgus/fmdb

你可以估计你的数据库的大小

- 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

【讨论】：

既然 Core Data 使用 SQLite，为什么还要使用 SQLite 而不是 Core Data？

这里是回答您问题的链接drdobbs.com/mobile/ios-data-storage-core-data-vs-sqlite/…

简而言之，核心数据会产生很多上下文，如果不想占用大量空间可以使用sqlite。当然，您可以使用核心数据，但在空间方面大约要大 2 倍

【参考方案2】：

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

作为参考，请检查您的 iPhone 首选项 -> 常规 -> 管理存储以了解其他应用的存储使用情况。

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