1

I need to define a large amount of data to be stored within an app and used as a lookup table. For instance, I have an array of manufacturer names, each with a mfg code. Each manufacturer can make different products, each with their own code as well.

A,7 could be deciphered to mean 

Manufacturer: Apple(A)
Product: MacMini(7)

I see several ways of defining this, but I'm not sure which would be best.

Option 1) #define these constants in a separate header file such as:

#define MFG_APPLE @"A"
#define MFG_DELL  @"B"

#define PRODUCT_MAC_MINI 7
#define PRODUCT_INSPIRON 2

Option 2) create a dictionary object filled with dictionary objects to allow me to index through them easier.

Option 3) use core data to create a database of these mfgs and products and relationships.

If option 2 or 3 is suggested, are there easy ways to pre-populate these data structures instead of hard-coding them to populate during program startup?

Option 4) Create a web service to tie this back to a server, where the data can be updated more often. A JSON query will send the mfg and product codes to the server, where it can respond with the mfg and product names.

4

1 回答 1

2

您应该考虑以下几点：如果数据库随应用程序一起提供，则每次必须更新数据库时，您都必须为应用程序发布更新。所以问题是，您需要多久更新一次数据？如果每隔几个月或一年更新一次数据库就可以了，那么将数据库与您的应用程序一起发布可能是一种选择，如果您需要每月甚至每周更新一次，您绝对应该将数据库托管在某处网络；在如此短的时间间隔内发布更新不是一个可行的选择。

您应该考虑的另一件事：如果数据库仅作为 Web 服务存在，并且每次查找都需要对服务器进行 JSON 调用，那么如果用户离线（目前没有任何网络访问权限）就无法执行查找原因）。此外，每次查找都会消耗用户流量，因此如果用户有每月限制，但每天需要执行大量查找，使用您的应用程序可能会很快导致他超过每月限制，导致他没有任何互联网服务（或非常节流一个）最后。

根据我的经验，最好在线托管这样的数据库，但如果可能的话，将其缓存以供离线访问。该应用程序本身附带一个数据库副本，该副本在您构建应用程序以进行分发的当天是最新的。每次启动应用程序时，如果应用程序永远不会退出，可能每天一次，它会向 Web 服务器查询数据库的当前“版本”。如果此版本比应用程序附带的版本更新，它会尝试将此数据库的副本下载到其本地缓存，然后切换到缓存副本以供将来查找。如果缓存的副本丢失（系统可能随时刷新缓存），则必须重新下载。同时，它可以使用已经过时的出厂数据库，但总比没有好。如果无法下载（例如设备上没有足够的可用空间），

所以基本上你的应用程序将有一个如下的工作流程：

  1. 开始
  2. 是否存在本地缓存副本？如果没有转到 6。
  3. 本地缓存的副本是最新的吗？如果没有转到 5。
  4. 使用本地缓存副本执行查找。转到 12。
  5. 删除过时的缓存副本。转到 1。
  6. 发货的数据库是最新的吗？如果没有转到 8。
  7. 使用随附的数据库执行查找。转到 12。
  8. 下载更新的数据库。
  9. 下载成功了吗？如果是，则转到 4。
  10. 用户当前在线？如果没有转到 7。
  11. 使用 JSON Web 服务执行查找。转到 12。
  12. 结尾

如果您将来只向数据库添加更多条目，而现有条目永远不会改变，那么还有另一个更好的选择：您只有两个数据库。一个随应用程序一起提供，一个只包含上次应用程序发布后的更新（添加的新条目）。这大大减少了需要下载和缓存的数据量。在这种情况下，您的应用程序必须始终执行两次查找，一次在交付的数据库中（始终首先执行），如果没有找到，则在下载的缓存副本中，其中不包含已在交付的数据库中找到的条目（或直接在线，如果没有可用的缓存副本，但用户当前可以访问 Internet）。每次发布应用程序的新更新时，它都会获得数据库的新完整副本，

用于下载的更新数据库甚至可以由服务器动态创建，这当然是最好的选择。例如，在发布应用程序后，您将 3 个供应商和 30 个产品添加到数据库中，并且每个供应商和产品都有一个唯一的 ID（随着添加的每个新条目严格增加），然后应用程序可以告诉服务器它是最高的供应商知道 ID 为 X，最高产品的 ID 为 Y，在这种情况下，服务器会发送一个更新数据库，其中包含 ID 高于 X 和 Y 的所有供应商和产品。

所有这些决定都会影响要使用的数据库格式。一般来说，这听起来很像 CoreData 的工作，但是如果您想要动态更新数据库，更新应该以不同的格式（JSON、XML、CVS 或其他服务器可以轻松生成的格式）交付并通过以下方式转换为 CoreData下载完成后的应用程序，因为在服务器上动态生成CoreData数据库相当困难，绝对不推荐。

于 2013-01-09T16:14:39.330 回答