Hi Rick,
One option is to use SQLite. I've been putting together an open source
"BFWQuery" library to hopefully simplify the whole thing, by letting you treat
a database query just like an array of dictionaries. It uses FMDB (thanks Gus).
eg: query.resultArray[row][columnName]
Here is an example:
BFWDatabase* database = [[BFWDatabase alloc] initWithPath:[self databasePath]];
BFWQuery* query = [[BFWQuery alloc] initWithDatabase:database
queryString:@"select Name, Latitude,
Longitude from Country where Language = ? and Latitude > ? order by Name"
arguments:@[@"English", @30.0]];
for (NSDictionary* rowDict in query.resultArray) {
NSLog(@"%@: (%@, %@)", rowDict[@"Name"], rowDict[@"Latitude"],
rowDict[@"Longitude"]);
}
Or to just get row 3's value for Name:
query.resultArray[3][@"Name"];
That's all there is to it.
Behind the scenes, BFWQuery only retrieves rows from the database as requested,
so it doesn't create an in memory array containing all of the results.
Since it's SQL, you can create your own relationships and efficient database
schema, which should perform better than CoreData.
You can also change the data with method calls like:
[database updateTable:@"Country"
rowDict:@{@"Name":@"Oz"}
whereDict:@{@"Name":@"Australia"}];
See:
https://bitbucket.org/barefeetware/bfwquery
Tom
Tom Brodhurst-Hill
BareFeetWare 👣
--
iPhone/iPad/iPod and Mac software development, specialising in databases
develo...@barefeetware.com
--
Follow us on Twitter: http://twitter.com/barefeetware/
Like us on Facebook: http://www.facebook.com/BareFeetWare
----
On 9 Apr 2014, at 8:13 am, Rick Mann <rm...@latencyzero.com> wrote:
> I'm generally a big fan of Core Data, but I'm developing a moderately
> complicated CAD app with libraries and design documents and such, and
> beginning to wonder if it would be easier to do if I weren't fighting Core
> Data. I'm wondering what the tradeoffs might be.
>
> If I were to dump Core Data, I'd keep the entire object graph in memory all
> the time, writing it out completely each time. I'd probably write XML, or
> some other text-based format (as much as I abhor text-based formats) because
> of the ease in diffing changes and using it with source control.
>
> As I write this, I realize that I can't just keep a whole document in memory;
> the library (which would be a collection of separate files on disk, but
> presented as a unified collection of content in the UI) could be very large
> and I'd rather not load in the whole thing. Nevertheless, I think that's
> doable.
>
> I'd have to handle relationships myself, but all the data types become easier
> to manage (I use a lot of C structs, well, really C++ structs).
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
