0

I'm writing an app in core data and I need to store an address which includes a state. Is there a concept of foreign key in core data (similar to sql) that will store a reference to a state entity (and enforce it)?

Now I know that Core data has relationships but they are supposed to be 2 way. This does not make much sense in this case.

Thanks

Joe.b
  • 372
  • 3
  • 16
  • 2
    A relationship *is* the proper way to go in Core Data. There good reasons to define an inverse relationship, even if you don't need it, see for example http://stackoverflow.com/questions/764125/does-every-core-data-relationship-have-to-have-an-inverse. – Martin R Dec 19 '15 at 15:14
  • Thanks. I saw that but was hoping there is a different way. It seems wasteful to store the inverse when not needed. Say you have 50k addresses with the same state then that state will have an nsset with 50k entries in it? – Joe.b Dec 19 '15 at 15:23
  • 1
    When designing a model for CoreData, I find it best to temporarily forget that there's a database involved at all. It's at its best when used as a way to save objects and the references between them. If your data is more suited to tables, rows, and keys, you may want to use SQLite directly. – Phillip Mills Dec 19 '15 at 15:23
  • @PhillipMills I come from working with relational databases so that's why I'm thinking this way. But from a core data developer what is the general practice for handling such situations? Don't want to reinvent the wheel. – Joe.b Dec 19 '15 at 15:40
  • When I started using CoreData my only experience with Databases was Filemaker which isn't SQL but also uses foreign keys. A relationship is comparable to a foreign key. Don't think about it as storing all the children in the parent. Only a reference (or key) to all children is stored in the parent. So if your main concern is overhead, then worry no more. There really isn't much. Since CoreData uses `Sets` which have `Hashable` elements there is also no considerable penalty for searching in large collections. – R Menke Dec 19 '15 at 16:36
  • Thanks guys. It seems relationships are the way to go. Will try it out and see how it goes. – Joe.b Dec 19 '15 at 16:52
  • Thinking in terms of relational databases is one of the best ways to mess up Core Data. – Tom Harrington Dec 21 '15 at 04:20

0 Answers0