CODEWITHSUNDEEP
iossqlitecore-data
Voloda2
Voloda2

Reputation: 12617

Which is the best solutions to store a data (coredata or sql)?

I'm developing a quiz application. I have 100 questions. For example, what city is the capital of Great Britain?

A. Rome

B. Milan

C. London

D. Oslo

Which is the best solutions to store a data (coredata or sql)?

Upvotes: 0

Views: 902

Answers (3)

EricS
EricS

Reputation: 9768

For a simple question/answer database with only 100 entries I would use a plain text file.

It's simple to create, edit, and read. It's cross-platform should you ever want an Android or other version of your application.

You could use XML, JSON, or a plist (as mentioned above) but why bother? Just alternate lines between questions and answers. Read in the file using [NSString stringWithContentsOfFile] and split up the lines into an array using [myFileContentString componentsSeparatedByString:@"\n"].

NSError *error = nil;
NSArray *testArray = [[NSString stringWithContentsOfFile:path encoding:NSUTF8StringEncoding error:&error] componentsSeparatedByString:@"\n"];

It's 1-2 lines of code and no learning curve. The odd entries in the array will be the questions and the even entries will be the answers.

(Reading a plist requires only one line of code, which is nice, but they're harder to edit by hand and aren't simple to read on other platforms should you ever branch out)

Upvotes: 1

Jack Lawrence
Jack Lawrence

Reputation: 10782

Core Data is a bit more complex to set up than SQL, however in my opinion Core Data is MUCH easier to work with, and keeps you in "objective-c land" where as SQL requires writing tons of SQL statements (as far as I know).

Specific to your use-case, I would think CoreData would be a better fit. You would probably have a Question object with an NSString text property for the actual question and then an NSArray of Answer objects. In CoreData/SQL speak, you would have a table of Questions with a text column. Each Question has a to-many relationship with a table of Answer objects (CoreData handles the dirty work for relationships, but in SQL you'd use primary keys).

As I said in a comment on another answer below, because your database isn't very large and complex initially, you could package a plist or download one from a server to initially populate the CoreData database. Using CoreData instead of a plist means it's much easier to update values on the fly, so you can do things like have a property on each answer object that you can set if the user chooses that answer so you can save state between launches.

Check out Core Data vs SQLite 3 and many other stack overflow answers that talk about the pros and cons of several different methods.

Upvotes: 3

xCoder
xCoder

Reputation: 725

You could also consider just using a .plist file with an array. Your data is not that complex (from what I understand), and plist makes for easy external maintaining/reading and updating via http.

Upvotes: 0

Related Questions