Re: Data managment
Re: Data managment
- Subject: Re: Data managment
- From: Dru Satori <email@hidden>
- Date: Mon, 12 Apr 2010 13:54:28 -0400
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@hidden> 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@hidden)
>
> 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:
>
> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden