0

I have a question about some foundational designing of coredata to make it future proof for my app!

Heres the scenario, lets consider im developing a coredata model to track Body mass index, (BMI), which is just one example and it will be listed in an entity named: Category.

Category has the following attributes:

  • NSString(String)Title (Weight)
  • NSNumber(float) upperMax (100) *
  • NSNumber(float) lowerMax (40) *

*Note: Those upper and lower limits are completely hypothetical and have no scientific basis at all, im just using it for my example! ahem..

Another Entity : "Tracker"

  • NSDate timeStamp
  • NSNumber entry

to-many relationship exists here - Category<--->>Tracker.

Uptil here, everything is well understood. The user enters inserts the tracker with the timeStamp and enters the value(current recorded weight), the application then compares if its above or below or between(normal) the preset values in category.

What If I add another category - Body mass index (BMI). BMI compares weight to height.

I can easily add them as a new cateogry in Entity as:

  • Name BMI
  • UpperMax 23.5
  • LowerMax 18.5

and user will add the track entries that compares the two.

But I want to be able to add weight AND height and not the BMI index it self, this creates a scenario where the user will enter values to two textfields.

the most obvious answer was to add another entry in Category called "Height", but then I'd have to create a new one to relate that with BMI.

Instead, im wondering about a new approach to design the cateogory entity in such a way that the Entry values can be user specified. eg. ( the Weight in "Weight") = required textfield input is ONE eg2. (weight and height in "BMI") = required textfield input is TWO.

Maybe i should create a new entity? with the name "fields" and store the category and specify the normal values number of required fields in this new entity.

Its pretty vague right now hope you get the idea of what im asking.

FROM A user's perspective: I want to be able to add "customised" categories in the app at runtime itself. Like in creating a "new" category, I'll add the Name and Add fields to the category using "add" button in the tableView.

In BMI, I'll add two fields Name: 1-Weight UpperMax/LowerMax etc. 2-Height etc..

Then when I tap "new Entrys to track growth" Two textFields should appear based on the count of Category.fields (relationship).

Is this the right approach? and how should i be connecting the "Category" entity with the "Entry" entity. I got "Fields" entity somewhere in the middle

user134611
  • 766
  • 1
  • 11
  • 22
  • 1
    If I understood you correctly, you are trying to weigh your options on whether you should use clearly defined coredata fields (entities) versus creating a table where you define your fields via rows in the table? If that is the case, I would base my answer on how many times you plan on adding or changing field definitions. Rows are easier to add, modify, and remove, but might be a little harder to work with. Actual fields are more definitive and might be easier to work with. – Brain2000 Jan 25 '12 at 16:35
  • I want to be able to add "customised" categories in the app at runtime itself. Like in creating a "new" category, I'll add the Name and Add fields to the category using "add" button in the tableView. In BMI, I'll add two fields Name: 1-Weight UpperMax/LowerMax etc. 2-Height etc.. Then when I tap "new Entrys to track growth" Two textFields should appear based on the count of Category.fields (relationship). Is this the right approach? and how should i be connecting the "Category" entity with the "Entry" entity. I got "Fields" entity somewhere in the middle. – user134611 Jan 25 '12 at 17:00
  • Yes, what you are describing sounds like the right way to go. To add customized categories at runtime, just add rows to the categories table. To link them, create a relationship entity between the category and entry tables. Then each entry object that you have will have an associated category. And each category object will have an array of entries. Does that make sense? – Brain2000 Jan 26 '12 at 19:10
  • hmm, its is making some sense, But the challenge is to figure out the relationship of that Entry to the associated category, or as i called it 'field'. Should it be a one-to-one? Every entry can have only one field. Like a weight Entry can have only a field type of Weight... And I add one entry like this, how will that behave the duplicate behavior... hmm...should the 'field' have<--->> one-to-many relationship with entry. field<--->>entry. Im almost there... not just yet.. – user134611 Jan 27 '12 at 01:57

1 Answers1

0

Have you taken a look at the Apple's documentation on CoreData? They have good examples to get a beginner get started with CoreData.

I suggest you visit the following link :

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/cdProgrammingGuide.html#//apple_ref/doc/uid/TP40001075

Quasar
  • 137
  • 3