Home/ Questions/Q 1032691
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T14:07:03+00:00

I am building an iPhone application that will be using a weighted graph (probably

  • 0

I am building an iPhone application that will be using a weighted graph (probably around 1000 nodes and 500-700 relationships, ball park estimate, could be quite wrong).

Core data would be wonderful since it’s easy to work with and is optimized for the iPhone. At the same time, the graph nodes need to be weighted. I could add a level of indirection (edit/clarification: I would represent the weighted edges as relationships.) in core data but feel that might defeat the point of the increase in performance.

SQLite would enable me to do it without any extra indirection the problem becomes performance.

Another consideration is that I use core data to store the stuff and then store only the weights in sqlite in tables and build custom core data objects that when I fetch or create creates the necessary links in sqlite and then just use the sqlite for calculation (since the calculation would only be traversing and looking at weights, so I don’t need anything but the final result/id of the object). I then would look up the actually object in core data.

Also, there will be a server that is taking in consideration all of the users graphs into a much larger graph. So it might be easier to use sqlite straight up since replicating the information on the beastly server would be easier 🙂

Thanks for the help.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    At first glance, Core Data is wonderful for your use case because its an object graph management framework (with persistence). It’s lazy loading and caching features allow you to load a partial graph in memory, which is usually desired if you have a large graph.

    Core Data doesn’t seem to support weighted relationship out of box (I’m not an Core Data expert at all). If “a level of indirection” means Core Data objects representing relationships, I agree it will be a performance hit.

    For performance and portability considerations, straight SQLite may be a better choice because you have complete control over the schemas and indices.

    I vote for your idea of “store only the weights in sqlite”. In my understanding, this allows you to take advantage of Core Data features while keeping performance critical tasks efficient.

    The author of NetNewsWire has written a blog article explaining why he has switched away from Core Data (mostly because performance and flexibility reasons) which may be helpful for you. http://inessential.com/2010/02/26/on_switching_away_from_core_data

    • 0