0

I'm a bit confused with Sqlite, Core Data, NSUserDefaultsand PropertyList. I know what is what, but not a very clear idea of about where to appropriately use them.

I know that there are lots of tutorials, but I'm good at learning through situation based understanding. So kindly do help me to understand this in the situation that I'm facing right now and to make use of the available options wisely.

I'm working on an ECommerce iOS (native) application, where I'm highly dependent on API's for data display. Now I'm in need of recording user's review for a product and send it over through an API.

ie. I have three components, rating title, rating value(for that title) and another rating title ID. I'm defining with an example, I need to store multiple rows with details,

Components             Data to be stored

**Title**    -   Quality |  Value  | Price
                         |         |
**Rating**   -     2     |   3     |   1
                         |         |
**TitleID**  -     10    |   11    |   12

Like this, there will be so many entries, i.e, the number of components differs for various users, for some users, there might be more than three components, which must be saved & send through an API. So how should I save these data? which is the RIGHT way to save these data temporarily?

rajesh s
  • 347
  • 1
  • 5
  • 12
  • what exactly, you want the way to save data to local db ? – vaibhav Oct 12 '16 at 12:32
  • I'd clearly mentioned that, the best option to choose from (Sqlite, Core Data, NSUserDefaults and PropertyList). Thanks for making it simple, the question is that, the right way to store/retrieve data locally, to match the situation I said. – rajesh s Oct 14 '16 at 04:59
  • so then i think your ques should have to mark as dupe, [have a look first](http://stackoverflow.com/help/how-to-ask), [this one also](http://www.wikihow.com/Ask-a-Question-on-Stack-Overflow). Plenty of comparisons are already exists and if you want to go in deep so you must spend some hours with particular topic [have a look about your ques](https://www.google.co.in/?gws_rd=ssl#q=sqlite+or+core+data+ios), [this one](http://stackoverflow.com/questions/4964408/should-i-save-in-plist-or-core-data), [this one also](http://stackoverflow.com/questions/30892619/core-data-vs-sqlite),. – vaibhav Oct 14 '16 at 07:30
  • Sorry to say this, even after defining the question in an elaborated manner, you altered the course by asking, `what exactly, you want the way to save data to local db` If the question was so simple, I would've asked it just like that. – rajesh s Oct 14 '16 at 08:45
  • So i think it could be the way for sqlite, coredata, plist with explanation, anyway i think you got your point now look at the dan ans and *consider if* for other users. – vaibhav Oct 14 '16 at 09:20
  • Even with the added explanation, I'd stick with the more complex approach at the end below, which would only be practical in Sqlite or CoreData from your alternatives and, given that you're using Swift, my clear preference would be CoreData. I've used CoreData for similar structures - you do end up with a lot of records, but they're quite manageable with that tool and the performance can be quick if the tables are structured well even when you get into 100s of thousands of records. Breaking up responses this way also supports flexible management reporting down the road. – Ron Diel Oct 14 '16 at 17:36
  • @vaibhav that's okay, I'd been working on Dan 's answer lately. – rajesh s Oct 15 '16 at 10:26

1 Answers1

0

If I understand you correctly, as vaibhav implied your question seems pretty general and probably relates more to structuring your data to fit your requirements than to technical aspects of the iOS / CoreData environment. In that vein, I’ll offer a few thoughts I’d have in structuring a data structure for quality ratings per your description.

If your ratings will always be for the three categories you show, i.e. Quality, Value and Price, I wouldn’t over-complicate things; I’d just use three properties in a rating record to hold the values that a user assigns in his/her rating of a product (just showing selected attributes and relationships in all following lists):

Product
    name

Rating
    ratedProduct   (many to one)
    qualityRating  Int
    valueRating    Int
    priceRating    Int

Done this way you’d need to associate the values with their types in code for the APIs, such as (where item is a retrieved rating record):

display(product: item.ratedProduct.name, quality: item.qualityRating, value: item.valueRating, price: item.priceRating).

On the other hand, you may be describing a more generic approach that would allow for ratings categories that vary more frequently, or perhaps vary among products. This could apply where, for example, ratings include how well things fit for clothing but not for other products like books. In that case, you’d need a more complicated structure where a product could have a variable number of ratings of different types, so you’d need another layer of entities that let you create an arbitrary number of rating records that applied to a product.

Here you'd create a separate rating record for each rating that a user assigned to a product.

The simplest form of that structure would be like the following:

Product
    name          String

UserEvaluation
    ratedProduct  (many to one)
    productRating (one to many)

ProductRating
    ratingType    (many to one)
    value         Int

RatingType
    ratingTitle   String
    ratingID      String or Int

Then you’d have to have a bit more structure where you'd list the product and then access the ratings with a loop that cycled through the set of all of the ratings linked to the product record somewhat like this (where item is a retrieved UserEvaluation):

displayTitle(product: item.ratedProduct.name)
for rating in item.productRating {
    displayRating(ratingTitle: item.productRating.ratingType.title, ratingValue: item.productRating.value)
 }

You'd probably want to combine these into a method that takes the name and an array of ratings.

To keep track of things, you’d also probably want to create another entity that defined product classes and specified what specialized ratings applied to each class (like fit for clothing and mileage for cars). By default, you also may want to allow for a few generic rating types that apply to all products (like the quality and price ratings you show). For this approach, the full structure would look like this:

Product Category
    title
    ratingType    (many to many)

Product
    productType   (many to one)

UserEvaluation
    ratedProduct  (many to one)
    productRating (one to many)

ProductRating
    ratingType    (many to one)
    value         Int

RatingType
    ratingTitle   String
    ratingID      String or Int

With this structure, once a product is assigned a productType, the application would know what ratings to ask for in the UI.

You could try building more complicated rating records with all of the types that apply to a product category, but that would get very messy if the applicable categories vary over time. You could also create a "custom" rating type that let a user specify a title and input a rating, in which case you'd need a text field in the rating record that only applies if the ratingType is "custom".

I hope this helps…

Ron Diel
  • 1,354
  • 7
  • 10
  • Thank you for the great explanation, I'd been trying to implement your suggestion, I'll get back after getting that up to the working state, please wait. – rajesh s Oct 15 '16 at 10:28