Database
iOS Data Storage: Core Data vs. SQLite
By Dean Gereaux, August 12, 2014
A sample application tests the benefits and drawbacks of each.Related Reading
More Insights
White Papers
- Defending Corporate Executives and VIPs from Cyberattacks
- Business Buyers Guide to Password Managers
Reports
More >>
INFO-LINK
Currently we allow the following HTML tags in comments:
Single tags
These tags can be used alone and don't need an ending tag.
<br> Defines a single line break
<hr> Defines a horizontal line
Matching tags
These require an ending tag - e.g. <i>italic text</i>
<a> Defines an anchor
<b> Defines bold text
<big> Defines big text
<blockquote> Defines a long quotation
<caption> Defines a table caption
<cite> Defines a citation
<code> Defines computer code text
<em> Defines emphasized text
<fieldset> Defines a border around elements in a form
<h1> This is heading 1
<h2> This is heading 2
<h3> This is heading 3
<h4> This is heading 4
<h5> This is heading 5
<h6> This is heading 6
<i> Defines italic text
<p> Defines a paragraph
<pre> Defines preformatted text
<q> Defines a short quotation
<samp> Defines sample computer code text
<small> Defines small text
<span> Defines a section in a document
<s> Defines strikethrough text
<strike> Defines strikethrough text
<strong> Defines strong text
<sub> Defines subscripted text
<sup> Defines superscripted text
<u> Defines underlined text
Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.
 |
To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy. |
KonranG583
Thanks for your great article - that was exactly that what I needed to understand and use CoreData for the first time.
One remark on your sample test application:
The results table view shows elapsed time for each row displayed. As you are caching/pre-fetching the data (either Sqlite or CoreData) prior to feed it into the table view, this time value is obsolete. I experienced by writing own test code, that a test without pre-fetching the data, but executing SQL or object retrieval code for each cellForRowAtIndexPath: gives interesting results:
One single Sqlite SQL execution and unpacking the column data takes approx. 2 ... 13 micro secs while one single CoreData object retrieval and parameters unpacking takes approx. 65 ... 90 milli secs. Measurements were taken on iPhone 6, 1 of 13134 data records, SQL statement with 3 table joins vs. CoreData fetch request with search predicate also on 1 of 13134 objects in storage.
Thus, a scroll in the results table view takes a noticeable time using CoreData and no delay with Sqlite. CoreData seems to offer advantage, when lots of data rows are retrieved at the same time.
