iphone sqlite core-data

iphone - sqlite swift



Datos básicos frente a SQLite para desarrolladores con experiencia en SQL (3)

Estamos comenzando a desarrollar una aplicación interna en el programa de desarrollo 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 los almacenaremos localmente, donde persistirán y deberán estar. 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.
  • Hay dos desarrolladores en este proyecto y ambos tenemos sólidas habilidades SQL, pero ninguno ha usado 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 utilizar las habilidades SQL existentes?

EDITAR: Acabo de ver esta pregunta: Datos principales frente a SQLite 3 . Supongo que mis preguntas por lo tanto son:

  • Si tengo que verificar si existe un elemento específico o si tiene una actualización, lo cual es fácil usando 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?

Como ha leído Core Data vs SQLite 3 , sabe que Core Data y el mecanismo de persistencia (SQLite en este caso) son en gran medida ortogonales. 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. Puede asignar un número de versión a toda la tienda persistente y recuperar esa información a través de +[NSPersistentStore metadataForPersistentStoreWithURL:error:] , sin siquiera 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.

Para no restar importancia a este foro, es posible que encuentre 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, por ejemplo, utilizando KVC / KVO o enlaces, entonces puede encontrar rápidamente que esta funcionalidad vale la pena la curva de aprendizaje.

= Mike

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

Entonces, la conclusión es, ¿tiene sentido dar forma a este proyecto? ¿Core Data me dará algo que no tenía en mi diseño original?

Suponiendo que el diseño original se realizó correctamente, de acuerdo con 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 mesa de dibujo, 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 tener 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.