views:

36

answers:

1

Per the Core Data Programming Guide:

You can specify that an attribute is optional—that is, it is not required to have a value. In general, however, you are discouraged from doing so—especially for numeric values (typically you can get better results using a mandatory attribute with a default value—in the model—of 0). The reason for this is that SQL has special comparison behavior for NULL that is unlike Objective-C's nil. NULL in a database is not the same as 0, and searches for 0 will not match columns with NULL.

I have always made numeric values non-optional, but have not for dates and strings. It is convenient in my code to base logic on dates and/or strings being nil.

Based on the above recommendations, I am considering making everything in my database non-optional. For dates I could set the model default to a value of 0 and for strings a model default of nothing (""). Then, in my code I could test dates for [date timeIntervalSince1970] != 0 and strings for string.length != 0.

The question is, for a relatively small database, does this really matter from a Core Data performance standpoint? And what is the tradeoff if the attribute in question will never be directly queried via a predicate?

+2  A: 

I have not seen any performance problems on small to medium sized data sets. I suspect that this is something you would deal with in the performance stage of your application.

Personally I use the same logic of non numerics being optional if it makes sense as it does indeed make the code easier which in turn gives me more time to optimize later.

Marcus S. Zarra
Thanks so much Marcus! I was hoping you would be the one to answer this. Coming from a certified Core Data ninja gives me the confidence to leave this issue behind me.
thevoid
If Marcus was really a Core Data ninja then we would never see him... unless that's what he wants us to think. Ninja are tricky devils.
TechZen