Another consideration is: Is this a project that could ever need a multi-user or networked data engine?
If the above answer is yes, then CoreData is probably a bad option (though Marko's excellent BaseTen for PostgreSQL might be an option in that case), as the options for migrating Managed Objects to network databases are limited. That is part of the problem, 'Data' is such a relative term, and without knowing the goal of the application, it is tough to provide a good scalable alternative. From first hand experience, one of the projects I am working on is in some of this box. One application that can be used standalone, or always on multi-user or with multiple disconnected users synchronizing data when peered. Complex? You have no idea. But in the design process, many decisions had to be made, that meant architecture and implementation. The end result for me? a client server design that uses a multi-user capable database engine even when in stand-alone single user mode. When you start the application, it starts the embedded database engine. While this is massive overkill for most implementations, it is still a very real design, IF your project demands it. Andy 'Dru' Satori On Apr 12, 2010, at 12:33 PM, Jens Alfke <[email protected]> wrote: > > On Apr 12, 2010, at 7:36 AM, Billy Flatman wrote: > >> Is it possible to get core data data models to save differently, one for a >> document save which for example might be an XML format, and one into the >> applications bundle as an SQLite file? >> That way when a document is saved the main database won't be duplicated, >> just the document specific data. > > You can have different documents with different data models, without needing > to use different on-disk data formats. In other words, you can have two > different document types both of which use SQLite. > > CoreData is very powerful, but it’s going to take over your app — you’ll end > up writing everything using managed objects and bindings. Which can be good, > but there’s a whole ‘nother learning curve for that. It can be easier to just > use a data storage API directly even if it doesn’t get you all the bells and > whistles. > > If you want to go with SQLite, you might consider using one of the Cocoa > adapter libraries so you can use an Objective-C API and not have to deal with > translating between char* and NSString all the time. The two I know of are > FMDB and QuickLite. > > There are also other data storage libraries that have a simpler data model > than sqlite (they’re like on-disk NSDictionaries) so they’re a bit simpler to > use and can potentially run faster. Tokyo Cabinet seems like the main > contender in that area right now. It comes with C and C++ APIs; I don’t know > if anyone’s adapted it to Objective-C yet. > > —Jens_______________________________________________ > > Cocoa-dev mailing list ([email protected]) > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/dru%40druware.com > > This email sent to [email protected] > _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
