Datos básicos vs SQLite 3 [cerrado]
Ya estoy bastante familiarizado con las bases de datos relacionales y he usado SQLite (y otras bases de datos) en el pasado. Sin embargo, Core Data tiene cierto atractivo, por lo que estoy considerando dedicar algo de tiempo a aprenderlo y usarlo en mi próxima aplicación.
¿Hay muchos beneficios en utilizar Core Data en lugar de SQLite, o viceversa? ¿Cuáles son los pros y los contras de cada uno?
Me resulta difícil justificar el costo de aprender Core Data cuando Apple no lo usa para muchas de sus aplicaciones emblemáticas como Mail.app o iPhoto.app, sino que opta por bases de datos SQLite. SQLite también se usa ampliamente en el iPhone.
¿Pueden aquellos que estén familiarizados con el uso de ambos comentar su experiencia? ¿Quizás, como ocurre con la mayoría de las cosas, la pregunta es más profunda que simplemente usar uno sobre el otro?
Aunque Core Data es un descendiente de Enterprise Object Framework de Apple , un mapeador relacional de objetos (ORM) que estaba/está estrechamente vinculado a un backend relacional, Core Data no es un ORM. De hecho, es un marco de gestión de gráficos de objetos. Gestiona un gráfico potencialmente muy grande de instancias de objetos, lo que permite que una aplicación funcione con un gráfico que no encajaría completamente en la memoria al introducir y sacar objetos de la memoria según sea necesario. Core Data también gestiona restricciones sobre propiedades y relaciones y mantiene la integridad de las referencias (por ejemplo, manteniendo los vínculos hacia adelante y hacia atrás consistentes cuando se agregan/eliminan objetos a/desde una relación). Core Data es, por tanto, un marco ideal para construir el componente "modelo" de una arquitectura MVC.
Para implementar su gestión de gráficos, Core Data utiliza SQLite como almacén de discos. Podría haberse implementado utilizando una base de datos relacional diferente o incluso una base de datos no relacional como CouchDB . Como otros han señalado, Core Data también puede usar XML o un formato binario o un formato atómico escrito por el usuario como backend (aunque estas opciones requieren que todo el gráfico del objeto quepa en la memoria). Si está interesado en cómo se implementan Core Data en un backend SQLite, es posible que desee consultar el marco OmniDataObjects de OmniGroup , una implementación de código abierto de un subconjunto de Core Data API. El marco BaseTen también es una implementación de Core Data API que utiliza PostgreSQL como backend.
Debido a que Core Data no pretende ser un ORM para SQLite, no puede leer esquemas SQLite arbitrarios. Por el contrario, no debe confiar en poder leer los almacenes de datos SQLite de Core Data con otras herramientas SQLite; el esquema es un detalle de implementación que puede cambiar.
Por lo tanto, realmente no existe ningún conflicto entre usar Core Data o SQLite directamente. Si desea una base de datos relacional, use SQLite (directamente o mediante uno de los contenedores de Objective-C como FMDB ) o un servidor de base de datos relacional. Sin embargo, es posible que aún quieras aprender Core Data para usarlo como marco de gestión de gráficos de objetos. En combinación con las clases de controlador de Apple y los widgets de vista compatibles con el enlace clave-valor, puede implementar una arquitectura MVC completa con muy poco código.
Y con iOS 5.0 obtienes el beneficio adicional de poder usar la sincronización de archivos de iCloud de forma gratuita si usas Core Data. Si está utilizando SQLite directamente, tendrá que realizar muchos ajustes e implementación manuales para sincronizarlo en iCloud.
Core Data no es tanto un motor de base de datos sino una API que abstrae el almacén de datos real. Puede indicarle a Core Data que guarde como una base de datos sqlite, un plist, un archivo binario o incluso un tipo de almacén de datos personalizado.
Recomendaría aprender Core Data, ya que es un recurso excelente que acelera enormemente muchas partes del desarrollo de aplicaciones de cacao.
