Datos principales frente a SQLite para desarrolladores con experiencia en SQL

Question

Estamos comenzando a desarrollar una aplicación interna en el programa para desarrolladores de iPhone Enterprise. Como está cerca de OS 3.0, reconsideramos nuestro diseño original de usar SQLite y usar Core Data en su lugar. Aquí hay algo más de información:

• Hay una aplicación de escritorio heredada que está reemplazando. Reutilizaremos el back-end existente.
• Actualmente tenemos una base de datos SQLite generada como una prueba de concepto. Esta es básicamente una versión reducida de la base de datos back-end existente.
• Cargaremos datos de un sitio remoto y lo almacenaremos localmente, donde persistirá y será necesario que lo esté. Solo lo actualizamos si ha cambiado, que será cada mes o dos. Lo más probable es que usemos XML o JSON para transferir los datos.
• Existen dos desarrolladores en este proyecto y ambos tenemos sólidas habilidades SQL, pero ninguna de ellas ha utilizado Core Data.

Mis preguntas son: ¿cuál es el beneficio de Core Data en SQLite, cuál sería el beneficio en esta instancia específica y los beneficios justifican aprender un nuevo marco en lugar de usar las habilidades SQL existentes?

EDIT: Acabo de notar esta pregunta: Core Data vs SQLite 3. Supongo que mis preguntas son por lo tanto:

• Si tengo que verificar si existe un elemento específico o si tiene una actualización, lo cual es fácil con SQL, ¿los Datos Básicos aún tienen sentido? ¿Puedo cargar el primer objeto en un gráfico y verificar el número de versión sin cargar todo el gráfico?
• Si ya conocemos SQL, ¿las ventajas de Core Data para este proyecto justifican que lo aprendamos?

Answer 1

Como usted ha leído Core Data vs SQLite 3, sabe que datos básicos y el mecanismo de persistencia (SQLite en este caso) son en gran parte ortogonal. Core Data se trata realmente de administrar un gráfico de objetos y su caso de uso principal es para el componente de modelo de una arquitectura MVC. Si su aplicación se adapta muy bien a esta arquitectura, probablemente valga la pena utilizar Core Data, ya que le ahorrará una gran cantidad de código en el componente del modelo. Si ya tiene un componente de modelo en funcionamiento (por ejemplo, desde la aplicación de escritorio existente), Core Data no le comprará mucho. Es posible un enfoque híbrido: puede hacer su propia persistencia/consulta y crear un Core Data en la memoria de la tienda que rellene con el resultado de una consulta y utilizar este almacén en memoria a través de Core Data como componente modelo para su aplicación. Esto no es común, pero lo he hecho y no hay obstáculos importantes.

para responder a sus preguntas específicas:

1. Se puede asignar un número de versión a todo el almacén persistente y recuperar esa información a través de +[NSPersistentStore metadataForPersistentStoreWithURL:error:], sin necesidad de abrir la tienda. Un equivalente +setMetadata:forPersistentStoreWithURL:error también existe, por supuesto. Si desea almacenar la información de la versión en una instancia de entidad en lugar de en los metadatos de la tienda persistente, puede cargar solo un objeto. Con una tienda persistente SQLite, Core Data hace un muy buen trabajo al obtener solo lo que necesita.

2. La API NSPredicate, es muy fácil de aprender y parece hacer un trabajo decente de compilación en SQL. Al menos para las bases de datos del tamaño que podría caber en un iPhone, sin duda ha sido adecuado (en lo que respecta al rendimiento) en mi experiencia. Sin embargo, creo que la pregunta SQL vs. Core Data está un poco equivocada. Una vez que obtenga el resultado de una consulta, ¿qué va a hacer con eso? Si imprime el suyo, tendrá que crear instancias de objetos, manejar fallas/exclusiones (si no desea cargar el resultado completo de una consulta en la memoria de inmediato) y todas las demás funciones de administración de gráficos de objetos que ya proporciona Core. Datos.

Answer 2

Parece que ya tiene el proyecto diseñado con SQLite, y tiene experiencia en esa área.

Por lo tanto, en resumidas cuentas, ¿tiene sentido portar este proyecto? ¿Core Data me dará cualquier cosa que no tenga en mi diseño original?

Suponiendo que el diseño original se realizó correctamente, según los requisitos EN ESTE PROYECTO, probablemente no valga la pena.

Pero ese no es el final de la discusión. Hay otras cosas en que pensar: ¿Mi próximo proyecto tendrá requisitos de base de datos tan livianos? ¿Tengo que enviar pronto, debido a limitaciones de tiempo o presupuesto? Asumiendo que voy a tener que aprender Core Data tarde o temprano, ¿no tiene sentido hacerlo ahora? ¿Estoy interesado en portar mi código a la Mac?

Las respuestas a estas preguntas pueden llevarlo a la decisión de que sí, de hecho vale la pena volver a la pizarra, por así decirlo, y aprender de qué se trata Core Data.

Para llegar a su pregunta final: ¿Cuáles son las ventajas? Bueno, Core Data es una abstracción de nivel superior de su base de datos, también es independiente del almacén de datos (por lo que si una versión futura del iPhone eliminara SQLite para una versión incrustada de MySQL ... poco probable, pero es un ejemplo) entonces Core Los datos requerirían MUY pocos cambios en el código para que funcione con el nuevo almacén de datos. Core Data proporcionará una gran cantidad de portabilidad rápida a la plataforma Mac. Core Data manejará las versiones de su modelo de datos, mientras que a menos que tenga un marco de trabajo o un flujo de trabajo para administrarlo, el acceso directo a SQLite no lo hará.

Estoy seguro de que otros respondedores pueden presentar otras ventajas, y tal vez algunas buenas razones para no meterse con Core Data. Por cierto, en una situación similar, mi decisión fue trasladarme al nivel más alto, al marco más nuevo. Pero en mi caso, era para un proyecto paralelo, y la fecha de envío y el presupuesto no eran factores.

Answer 3

Para no desmerecerte de este foro, pero es posible que encuentres más encuestados con experiencia contextualmente relevante en el iPhone de Apple DevForum.

Hablando desde una perspectiva puramente de gestión de proyectos, parece que sabes cómo construir lo que quieres construir usando SQLite, por lo que tendría más sentido para mí comenzar la ruta.

Dicho esto, CoreData se basa en SQLite y si está tratando de aprovechar otras partes del sistema junto con sus datos, p. usando KVC/KVO o enlaces, entonces puede encontrar rápidamente que esta funcionalidad vale la curva de aprendizaje.

= Mike