Question

For my app I thought of two different data models, but I cannot see which one would be the best both in performance and filesize. In my app I have to store Recipes, which will consist of an array with ingredients, an array with instructions, an array with tips and some properties to select some recipes (e.g. a rating, type of dish).

I thought of two different models. The first would be to convert the arrays to NSData and store them all in the Core Data model. As the array’s are localized that means that there will be multiple arrays of the same kind in there (e.g. instructionsEN, instructionsFR, instructionsNL). As it is not necessary to query the arrays I’m happy with the fact that I have to convert the arrays to NSData.

The other model would be a core data that only contains the properties to filter a recipe, and an identifier to a .plist file that is stored in the main bundle or the documents directory (as some of these files will be created by us, and some are created by the user). This .plist file will contain all the instructions, ingredients etc. Again, there are multiple arrays for the same kind for different localizations.

I hope you can help my with making my decision which of these options would be best in terms of performance and diskspace. I would also appreciate it if you could think of a different solution.

Answer 1

If you’re going to Core Data, you should generally go all the way. In that case, you would have an NSManagedObject Ingredient. I would probably put a method on Ingredient like stringValueForLocale: that would take care of returning me the best value. This means that a given ingredient can be translated once and is reusable for all recipes.

You would then have a Component entity that would have an Ingredient, a quantity value and a unit. A Recipe would have a 1:M property components that would point to these. Component should likely have an englishDescription as well, which would return a printable value like “1/4c sugar” while frenchDescription might print “50g de sucre” (note the volume/mass conversion there; Component is probably where you’d manage this.)

Instructions are a bit different, since they are less likely to be reusable. I guess you might get lucky and “Beat eggs to hard peaks.” might show up in several recipes, but unless you’re going to actively look for those kinds of reuse, it’s probably more trouble than it’s worth. Instructions are also the natural place to address cultural differences. In France, eggs are often stored at room temperature. In America, they are always refrigerated. To correctly translate a French recipe to American English, you sometimes have to include an extra step like “bring eggs to room temperature.” (But it depends on the recipe, since it doesn’t always matter.) It generally makes sense to do this in the instructions rather than in the Ingredients.

I’d probably create an Instructions entity with stringValuesForLocale: (that would return an array of strings). Then you could do some profiling and decide whether to break this up into separate LocalizedInstructions entities so that you didn’t have to fault all of the localization. The advantage of this design is that you can change you mind later about the internal database layout, and it doesn’t impact higher levels. In either case, however, I’d probably store the actual instructions as an NSData encoding an NSArray. It’s probably not worth the trouble and cost of creating a bunch of individual LocalizedInstruction entities.