Sqlite or coredata for complex data structure on ios

Question

I have a rather complicated data structure that I am going to use in an iPhone / iPad application. After getting rid of many unnecessary tables and smoothing the data structure as far as I can. - I.e. if I have a call table and an address table in a real structure, since I do not need to update the address information at all, I expanded the IOS call table to have address information rather than linking the table - basically de-normalized how can I reduce the complexity tables.

In total, I still have 15 tables.

I can easily script to use tables in SQLlite and played quickly with the SQLlite C API in iOS and work fine.

My question is: for an application with a lot of data to collect data with a lot of related tables, do I have to stick to my SQL skills and use SQLite and the C API or convert it all to coredata?

My main concerns with coredata - a) installation time - is there a way to create a core data card from an existing database schema (SQL Server, SQLite or scripts) b) if I have several thousand rows in one table (its list of stock items, which are used in the workplace). I understand that coredata extracts ALL elements for this object and then filters them using predicates. Is this how it works, or am I misunderstood? Is it effective if it behaves like this? c) Although I have smoothed the structure as much as possible, I still may need to join 3 or 4 tables together - in the master data are relations such as effective used?

I have no problem re-reading coredata books and then applying them, if this is really the best solution for this kind of scenario, its just all the books and examples that I read are 1 or 2 objects with several attributes with a single relation. My database schema, and therefore my coredata data model will be much more complicated than this. Another consideration: does the underlying data really provide any advantages over sqllite for using recreation services or JSON for receiving data from the server and sending data about the completion of the transfer to the server?

---

please check out my experience below: in case someone reads this post and wants to know my experience with SQL Server / ASP.net.

i started using SQLite, I found that it was fast enough and easy to use. The API was small, but as a SQL guy, this is not my phase.

i managed to script the table structure from SQL Server easily with small mods to the generated scripts that very quickly left me the table structure in SQLite

I started working in asp.net with access, so I'm no stranger to scripting and creating dynamic SQL strings. However, I no longer want to use this approach because I believe that it is deprecated, so although I probably overflowed when I used SQLite to retrieve the data, I wanted to put the data in the appropriate object. I wanted to create arrays of my objects and edit the attributes of my objects. it just makes sense to me in object C. In asp.net, I still DO NOT make objects for my data, I use SQL Server stored procedures, because I have a very complex data structure and you want to completely control everything that I request.

HOWEVER, AGES is required to create classes for creating tables. In the main data, this is one click to create a class that represents your main data object, so the tradeoff was manually spending the coredata schema and manually generating the classes to represent the data tables / entites / whatever you prefer to call them.

I have selected the basic data here.

YOU PROBABLY NEED TO USE CATEGORIES FOR EXTENDING REVERSE CLASSES, but in fact it is really simple and very cool,

One big advantage of coredata is the control controller, which automatically displays the changes in a table format. since my application has 2 or 3 types of tables that are hierarchical - changing the data in view 2 and then returning to the table, view 1 and viewing updates made in view 1 without manually reloading the data was very cool.

predicates are fine. they make enough sense, remember, no matter what object you choose, you can cut off relations with this OBJECT - also pretty cool, if sometimes a little messy - this is the completely reverse thinking from sql that I felt. Once you get used to it, its easy enough and powerful enough. At first it is a little strange.

NSManaged objects (any objects that you store in the master data) and their subclasses have their own managed context object - i.e. self.managedObjectContext creation is a bridge to explicitly save any changes, i.e.

 self.name=@ "james" self.favouriteColour=@ "blue" NSError * error; if ([self.managedObjectContext save:&error]) { NSLog(@"saved"); } 

which is MORE cleaner than setting up connections, commands and executing their sqlite etc.

The kernel data API is much cleaner than the SQLite API (well this is c).

Guess I'm an envelope!

Answer 1

First of all (and you probably heard this before): Core Data is not a database. This is a “life chart, search and preserve object graphics manager” and this article describes the differences better than I can: http://www.cocoawithlove.com/2010/02/differences-between-core-data-and. html

See also Use CoreData or SQLite on iPhone? and links there for more information that may help.

Now to your specific questions:

a) installation time - is there a way to create a coredata data map from an existing database schema (SQL Server, SQLite or scripts)

No. First, you must create a “model” of Core Data (using the Xcode model editor). A model consists of objects that have properties and relationships with other objects. Core Data has “persistent storage”, which can be a SQLite file (but also a “storage in memory”). The diagrams and tables used by Core Data are officially undocumented. You can try to directly create a SQLite Core Data datastore (the format is not too complicated), but the easiest way to transfer from SQLite to Core Data is probably to write your own code that reads SQLite tables and creates the corresponding Core Data objects.

b) if I have several thousand rows in one table (her list of stock items that are used in the workplace). I understand that coredata extracts ALL elements for this object and then filters them using predicates. Is this how it works, or am I misunderstood? Is it effective if it behaves like this?

Your understanding is wrong. Core Data uses “fetch requests” to retrieve data, optionally filters with a “predicate” and sorts with a “sort descriptor”. For SQLite-based storage, the query is translated into an SQL query and executed at the SQLite level. (This imposes restrictions on possible predicates, and not all SQL queries are possible with a select query.) Only loaded objects are loaded into memory.

c) Although I have smoothed out the structure as much as possible, it may still be necessary for me to join 3 or 4 tables together - basically, the data uses relations such as effective?

Yes.

... basic data provides any advantages over sqllite for consuming leisure services or JSON for receiving data from the server and transferring information about the completion of work on the server?

Perhaps look at RestKit , which supports master data. But I am not familiar with this, so I can not give more information about this issue.