I'm writing an iphone application that will be executing many queries over a database containing lots of data including geography and geometry types, but has a very simple schema. database obviously will be located on a server
here are my questions:
1. can core-data hold large databases
2. does core-data support geography and geometry types like spatial features in sql server and oracle databases?
3. what is the best practice and the recommended database when it comes to iphone applications
thank you
can core-data hold large databases
When it comes to databases, people have very different ideas of what "large" means. This answer nicely covers the limitations of Core Data; essentially, the limitations of Core Data depend on the underlying data store. On iOS, Core Data uses SQLite for data storage.
does core-data support geography and geometry types like spatial
features in sql server and oracle databases?
If you're thinking of Core Data as a database, you're really doing it wrong. Core Data is an object persistence manager. It doesn't have any spatial features; on the other hand, you can write whatever code you want in the objects you store in Core Data.
what is the best practice and the recommended database when it comes
to iphone applications
Naturally, that depends. If you want a traditional database, there's SQLite. If you have a large graph of objects to manage, use Core Data. If connectivity won't be an issue, web services connecting to a server-side database can be the way to go.
Usually, after working with online databases as well as Core Data, online databases with REST API are your best bet. I haven't seen the option to use special types like spatial features, Apple only gives you their basic types.
Related
I am working on a project using Ionic for the mobile side, I have a web app as well linked to a Cassandra database.
I need data synchronization between the mobile device (local storage) and the server-hosted Cassandra database. I use the cassandra-driver to connect to the database but then I realize how problematic it is to convert the data to an other type of database (SQLite for example).
Should I rather use an other database than Cassandra to make the synchronization easier ? (I need a noSQL solution)
Choice of the database depends on type of data you want to store. Cassandra is a column oriented database. It has great performance when you have to deal with large amount of data, but has many limitations related to the queries you need in order to pull data. For that reason, it might require additional efforts to develop something that you could easily do with some other database. So, the real question is do you really need Cassandra.
If you are using it only for mobile application, I don't think you will have so much data to exploit Cassandra benefits.
In your place, I would rather consider some other databases, such as MongoDB in case JSON is appropriate format for your data or Redis if you data is key/value pairs.
I am developing iPhone app for a web application currently running online. Current web application is big and complex and uses SQL to store vital information like member details, login credentials etx. Other stuffs like info about several sections, groups, sub groups and other information related to each are saved in txt. Current system uses its own standard to keep data in files and also made custom algorithm to read and write data in it. Each txt file is below 1 mb size. There are lot of data manipulations going on.
Custom algorithm created just read those files and put all data in cache as records (same as in core data managedobjectcontext) and whenever there is a change in data the whole file is overwritten.
So while implementing the same what I want to choose for iPhone app? In apple website they said that 'SQLite is perfect for low-level relational database work' https://developer.apple.com/technologies/ios/data-management.html But in my case it is high level.
So please help me to make a decision. Do I want to manage data in files or sqlite database using core data?
I would also like to know whether it is possible to import those classes and algorithms currently in webserver to iOS, so I don't want to rewrite the same algorithm for iOS? Current server codes are in C#
In the rare case that you need to do low-level relational database work use SQLite. In the 99% other cases use Core Data. Don't ever store relational stuff into txt files. It'll just be a pain.
Your use case sounds like a good match for Core Data.
Often misunderstood, Core Data is an object store that happens to use sqlite for persistence. You don't manipulate the sqlite underneath it, Core Data manage the sqlite for you. You do not write SQL. The closest match to it in .NET is EDM and the Entity Framework in ADO.NET.
Assuming the classes and algorithm you want to import in the webserver is in C#, sadly those needed to be ported to Obj-C.
We have native applications that run on Android, iOS, and Windows mobile. For other devices (such as BlackBerry) a mobile web solution. These applications currently do an initial large pull from our CMS and then parse XML from our CMS as its datastore. This data is then available offline on the device. We're looking for something more elegant than XML as we scale.
Here are options that we are weighing:
Option 1. Export a sqlite DB to Android, iOS, and Windows 7 phone that they would all then use as its datastore.
Pros: CMS exports the same data format to all devices
Cons: iOS isn't using CoreData like everything I've been reading says I should be using.
Option 2. Export sqlite DB to all platforms but have iOS insert data into CoreData. We are toying with idea of having CMS export JSON format to iOS and have iOS insert into CoreData since our delta updates to the application will be in JSON.
Pros: iOS is using CoreData and all of its benefits.
Cons: iOS now strays from all our other platforms such that it needs an intermediate solution (converting data into CoreData storage.)
Curious if anyone has mobile applications on various platforms that require persistent stores and how your team tackled it.
3/22/2013 for minor clarification and grammatical changes.
Stumbled upon this solution while doing research:
https://github.com/AlexDenisov/iActiveRecord
It behaves similarly to CoreData, such that it utilizes object graphs. It constructs the SQL statements behind the scenes for you so that you do not need to concern yourself with writing queries.
What I like about this solution is that iActiveRecord points to our exported SQLite DB from our CMS (which utilizes django) and we simply define our Obj-C class to match the schemas of the table (similar to defining data models in CoreData.) After the class schemas are defined to reflect our table schemas, we can start using objects without worrying about sql queries.
CoreData could not do this since it required us to write a "converter" to get exported data from our CMS into CoreData's datastore.
Of course all the extra bells and whistles of CoreData are missing, but for our use cases, utilizing iActiveRecord out weighed other options.
The real question is: can you really reuse any code on these platforms? Not much. Probably, too little to worry about it. In fact, if you don't have a common C/C++ library (in a broad sense, as in a set of functions) to process data in an SQLite database, there's not much code to reuse.
There may be cases where you heavily depend on certain SQL queries for good performance. Those queries may turn out to be very inefficient in Core Data. In this scenario I would go with SQLite and FMDB.
If the queries are simple enough and you mainly need to display/edit the data, then going with Core Data will be easier.
I recently started using RavenDb. I am converting a relational dbase to use RavenDb. I have two simple tables in the Relational dbase:
tbStates
tbCities
I have all US cities linked to a state. How can I go about converting this to no-sql. Will I have to write a little application to read from the relational dbase and create the objects? Or are there some tools out there I can use to do this?
There is a utility called smuger http://ravendb.net/documentation/smuggler but I imagine you will have to convert your data to Json. It may be just as easy to write a console app that reads the tables to objects then loads to Raven.
Just to add I migrated a SQL Server database to RavenDB using the console application route.
I used EF to quickly pull out the data and converted it to my RavenDB domain then added it to RavenDB.
It Worked well as you will most likely want to tweak the domain anyway to work best with RavenDB (For example I had an Images SQL table that I turned into a List on the document etc).
See Ayende's RacoonBlog project on github (https://github.com/ayende/RaccoonBlog) as he does something similar to move subtext data to RavenDB. RacoonBlog is the engine powering his blog and makes for good learning material about how to use RavenDB.
We're beginning development of an in-house app in the iPhone Enterprise developer program. Since it's close to OS 3.0, we're reconsidering our original design of using SQLite and using Core Data instead. Here's some more info:
There is a legacy desktop application that this is replacing. We will reuse the existing back end.
We currently have a SQLite database generated as a proof of concept. This is basically a cut down version of the existing back end database.
We will be loading data from a remote site and storing it locally, where it will persist and need to be . We only update it if it has changed, which will be every month or two. We will most likely use XML or JSON to transfer the data.
There are two developers on this project and we both have strong SQL skills but neither one has used Core Data.
My questions are: what is the benefit of Core Data over SQLite, what would the benefit be in this specific instance and do the benefits justify learning a new framework instead of using existing strong SQL skills?
EDIT:
I just noticed this question: Core Data vs SQLite 3. I guess my questions therefore are:
If I have to check if a specific item either exists or has an update, which is easy using SQL, does Core Data still make sense? Can I load the first object in a graph and check the version number without loading the whole graph?
If we already know SQL, does the advantages of Core Data for this one project justify us learning it?
As you've read Core Data vs SQLite 3, you know that Core Data and the persistence mechanism (SQLite in this case) are largely orthogonal. Core Data is really about managing an object graph and it's main use case is for the model component of an MVC architecture. If your application fits nicely into this architecture, it's probably worth using Core Data as it will save you a lot of code in the model component. If you already have a working model component (e.g. from the existing desktop app), then Core Data won't buy you much. A hybrid approach is possible-- you can do your own persistence/querying and build a Core Data in memory store which you populate with the result of a query and use this in-memory store via Core Data as the model component for your app. This isn't common, but I've done it and there are no major roadblocks.
To answer your specific questions:
You can assign a version number to the entire persistent store and retrieve that information via +[NSPersistentStore metadataForPersistentStoreWithURL:error:], without even opening the store. An equivalent +setMetadata:forPersistentStoreWithURL:error also exists, of course. If you want to store the version info in an entity instance instead of in the persistent store metadata, you can load only a single object. With an SQLite persistent store, Core Data does a very good job of fetching only what you need.
The NSPredicate API, is very easy to learn and it seems to do a decent job of compilation to SQL. At least for databases of the size you could fit on an iPhone it's certainly been adequate (performance wise) in my experience. I think the SQL vs. Core Data question is slightly misguided, however. Once you get the result of a query what are you going to do with it? If you roll your own, you'll have to instantiate objects, handle faulting/uniqueing (if you don't want to load the entire result of a query into memory immediately) and all of the other object graph management facilities already provided by Core Data.
It sounds like you already have the project designed using SQLite, and you have experience in that area.
So the bottom line is, does it make sense to port this project, will Core Data give me anything that I didn't already have in my original design?
Assuming that the original design was done properly, based on the requirements ON THIS PROJECT, it's probably not worth it.
But that's not the end of the discussion. There are other things to think about: Will my next project have such light database requirements? Do I need to ship soon, due to timeline or budget constraints? Assuming I'm going to have to learn Core Data sooner or later, doesn't it make sense to do it now? Am I possibly interested in porting my code over to the Mac?
The answers to these questions may lead you to the decision that yes, it is indeed worth it to go back to the drawing board so to speak, and learn what Core Data is all about.
To get to your final question: What are the advantages? Well, Core Data is a higher level abstraction of your database, it is also data store agnostic (so if a future version of the iPhone were to ditch SQLite for an embedded version of MySQL... unlikely, but it's an example) then Core Data would require VERY few changes to the code to make it work with the new data store. Core Data will provide a great deal of quick portability to the Mac platform. Core Data will handle versioning of your data model, whereas unless you have a framework or a workflow to manage it, direct access to SQLite won't.
I'm sure other answerers can come up with other advantages, and maybe some good reasons why NOT to mess with Core Data. Incidentally, in a similar situation, my decision was to port to the higher level, newer framework. But in my case, it was for a side project, and ship date and budget were non-factors.
Not to detract from this forum, but you might find more respondents with contextually relevant experience at the Apple iPhone DevForum.
Speaking from a purely project management perspective, it sounds like you know how to build what you want to build using SQLite, and so it would make more sense to me for you to start along that route.
That being said, CoreData builds on top of SQLite and if you are trying to leverage other parts of the system in conjunction with your data, e.g. using KVC/KVO or bindings, then you may quickly find that this functionality is worth the learning curve.
= Mike