I am fairly new to Objective C and iOS programming but am constantly trying to learn as much as I can.
I am about to start an iPad project which will involve storing large amounts of data which will need to be exported to one extremely large excel spreadsheet.(it's for a friend....they currently enter massive amounts of data into excel by hand so that they can analyze it).
This database contains over 400 names(this number is constantly growing) and the app will be very functionally similar to to built in contacts app, except that for each name there will be approximately 2,000 attributes. These attributes will be entered across tens, if not over a hundred views.
The excel file will be located on a local server and the database will be synced with it over wifi. If I have to write a server side application to handle this, I happily will.
My question is this:
What data storage method would serve best for my purpose accounting for the sheer size of the database and the need to export to excel? (i.e. CoreData?, SQLLite?, XML?)
I sincerely appreciate any help you might offer.
James
It'll be harder to create a CoreData store on the server end. I'd suggest using and SQLite DB. FMDB is decent frontend for using SQLite on the iPhone, but there are many others.
A framework for relational data such as Core Data or SQlite would work well for selecting and working with subsets of data. There's no innate export-to-Excel functionality but you could export a csv (comma-separated-value) file that Excel can import.
Related
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.
I am writing an iPhone app which would download articles (UTF8 text files) from my server. The app is then supposed to produce a listing of the filenames. Upon clicking the filename, the file contents would be displayed. It is very similar to an email program or RSS reader.
My question is, what is the best way of saving / retrieving the content on the device? One option is to put it all into a sqlite db. The other option could be to download the contents and save it in a new file. Any other solutions?
Any advantages/disadvantages for these approaches?
Thanks in advance
For some rather small amount of data in a simple structure you could store it in an NSMutableDictionary and use its methods for writing the content to file and for reading from a file.
Your data structure seems to be simple enough for that. If the amount of data is small enough I cannot say. If your list may grow endless then you shoud go for sqlite or for core data rather than a simple dictionay. A dictionary will be stored completely in RAM. With sqlite ore core data you can utilize RAM more efficiently by loading not much more records as are curently displayed.
I have a simple table that I'm pulling from our existing sql database. Its just a 1mb Vehicle table. It contains enough information that I don't want to create it from scratch, but I can not find a definitive answer on how to import this table into my sqlite environment on the mac.
I've seen a few posts about python scripts that import to Core Data but I don't think thats the way to go.
The table I saved out as .rpt file. Any direction other than the one I'm traveling would be great.
The most correct (and pretty easy) way to do this is to write a little Mac OS X command line tool program that reads the data from your SQLite database and uses Core Data to load the data into a Core Data persistent store.
That persistent store -- the resulting Core Data schema'd SQLite file -- can be added as a resource to your iOS app project and it'll "just work".
Checkout Christian Kienle's Core Data Editor, which let's you import data from CSV files into Core Data: http://christian-kienle.de/CoreDataEditor
It is also useful after the data is imported for debugging.
I hope all of you have had a good Christmas :-)
In my app i have a database, using Core Data, that requires a lot of data, at least 1.500 records consisting of 6 fields. That means at least 9.000 lines of data. All data is pure text.
During the development phase i have 250 records to test on.
The way i do populate the DB at this point is that i have a text (.txt) file, which i edit in Word and then reads into my database. This is very inconvenient for many reasons such as if i save it, by mistake, in the wrong format it all screws up (i have Swedish characters that changes).
Given the amount of records i will need i would like to ask for advice how people do these things and what to use? Is there some sort of (free) database available that i could use etc.
Cheers
For editing use notepad, notepad++, or gedit. You won't have issues with MS Word specific characters.
I am not too familiar with Core Data, but I believe it uses SQlite on the backend.
I have implemented SQLite directly into a few developments that I have worked on. It might be worth your time to take a look.
Can you give more details about your app? Platform, how often data is accessed, how often it is modified, etc.
Hmm, one way to get started on this might be to fill the Core Data store a single time, and then, whenever you need to run your tests, just copy this store file out of your application bundle into your documents directory. I maintain a "Reset All" function in a game I've worked on using this method, and it works great for very quickly populating Core Data.
Hej,
currently I am developing an app with very similar requirements - a prepopulated Core Data database with 1200+ entries with more or less the same amount of fields.
The data I receive is in xml format. I've written a small mac app which features the same core data model as the iphone app does - it will read the xml and create core data entries accordingly. I then take the database file my mac app created and add it to my iphone apps bundle, from where it will be copied to the documents folder on the first launch (or whenever a reset to the factory data is required).
This is working perfectly, I think you could do something very similar. The only difference would be that, instead of parsing xml, you'd need to write something that reads your textfile. Fear not, it's easy to do!
I've taken the approach to add a unit test that determines if the database exists. If the database doesn't exist, the test creates it from a text file (usually a plist or csv).
This approach enables me to: alter the underlying data via text, "clean" the database by simply deleting it, and run tests against the data. Since you're using CoreData, there might be some additional benefits by ensuring your schema matches the dataset; I once found I'd accidentally set an attribute to not allow nil.
I am developing an application in which i have to get data from .xls file. I am fairly new to iPhone development so any pointers in direction to getting started will be very much helpful.
The steps that i am thinking are :
1) First i need to convert from .xls to .csv Format.
2)Import the data from .csv file to SQlite Databse or Core Data.(I am not familiar with any one of them, so kindly suggest which one to choose. I am looking forward to use Core Data)
Am I thinking in the right direction? Will be greatful for any kind of assistance..
Thanks in advance.
While I cannot speak to the first part of your question, I can give you advice for the second. Because you are importing the data as opposed to writing back to the xls format, you want to go with Core Data. There is no reason to be using sqlite directly anymore.
I think sqlite is a good idea if you want to be able to use the same datastore with multiple different devices in the feature. If you are targeting iphone only then go with core data. Also a sqlite datastore can be loaded back in with core data on top at a latter date if you want all that caching ability.