Datos básicos VS Sqlite o FMDB ....?

Question

Ahora esto podría parecer un hilo duplicado, pero mi pregunta es que he leído muchas preguntas como ... Core Data vs SQLite 3 y otras, pero tienen entre 2 y 3 años. También he leído que FMDB fue desarrollado ya que los datos centrales no eran compatibles con iOS, por lo que no deberían usarse más. Y, por otro lado, he leído que no se deben usar datos básicos como base de datos.

Así que estoy seriamente confundido, si debo usar datos centrales para el almacenamiento de objetos o no. Me refiero a qué base debería decidir cuál usar? ¿Hay alguna guía provista por Apple u otra persona ... o es algo que me llegará con el tiempo?

Answer 1

Ankit,

Aquí el tl; dr delgado: use datos básicos.

Aquí es la forma larga:

Mientras que usted podría utilizar muchos criterios para elegir entre los datos básicos, un ORM (FMDB) o llamadas sqlite directos, el coste real de esta elección viene de su tiempo para utilizarla, de Apple apoyo y apalancamiento de otros proyectos. (RESTKit, que asigna los servicios REST a Core Data, es popular en estos días.)

Por lo tanto, un gran porcentaje del tiempo, digamos 90 +% (una estadística inventada), la respuesta en iOS será usar Datos principales. ¿Por qué? Una vez que lo domine y construya algunos pequeños métodos auxiliares, Core Data lo mantendrá en un mundo de computación constante, el gráfico de objetos Objective-C. Core Data le enseñará cosas sobre cómo usar un lenguaje dinámico que ayudará a todos los demás aspectos de la programación de su iOS. Por lo tanto, eres más productivo. No luches contra el marco.

Si trae un esquema grande y complejo de base de datos SQLite & desde otra aplicación, puede ser rentable usar FMDB o SQLite. Pero lo dudo. Su tiempo escribiendo una sencilla aplicación de línea de comandos basada en Mac para migrar el DB a un Core Data DB es una tarea finita y simple. Es casi seguro que tendrá que volver a escribir la mayor parte de la lógica empresarial en Objective-C. (Sí, C++ y Objective-C++ son buenas tecnologías. ¿Su lógica de negocio de base de datos realmente se ha ajustado para funcionar en un dispositivo con memoria limitada? No lo creo.)

Core Data tiene un rendimiento muy alto. Es realmente bastante rápido. Solo tiene que usarlo de manera diferente a como usa un DB. En particular, casi siempre extrae los datos de la tienda y luego los refina usando predicados directamente en los diversos conjuntos y matrices.En los dispositivos iOS, donde el flash es sorprendentemente lento, esta estrategia de búsqueda excesiva es particularmente efectiva. De hecho, tienes mucha RAM en estos dispositivos, úsala para obtener rendimiento. (Sí, sé que esto es una aparente contradicción con mi anterior lógica de negocios portátil. Pero en realidad, el código portado desde un entorno de escritorio o servidor tiene muchas suposiciones implícitas sobre la velocidad del disco, la cantidad de memoria y la realidad de una máquina virtual con una tienda de respaldo, simplemente no funcionará bien en un dispositivo de memoria limitado por batería con un modelo de memoria funky. [Tampoco funcionará muy bien en los dispositivos Android.]) También se desnormalizarán los datos para simplificar mostrándolo en varios widgets UI para iOS y Mac OS X. Hay algunas aplicaciones en las que los datos centrales serán más lentos que una base de datos SQLite equivalente. Esos han sido detallados en otra parte. El principal reclamo es que las tareas en las que los ID se definen por las coincidencias de bases de datos ascendentes El rendimiento de Core Data es verdadero. Pero se puede mitigar de alguna manera mediante una indexación juiciosa y una sobrecarga.

Lo que hay que recordar sobre los dispositivos móviles también es que el tamaño de la base de datos, debido a que estos dispositivos móviles están en las hojas de internet, generalmente es de tamaño modesto. Por lo tanto, el rendimiento es más fácil de lograr. Es posible que muchas lecciones del mundo de los servidores no se apliquen a este mundo móvil alimentado por baterías.

En otras palabras, debe utilizar "todo" para usar Objective-C en iOS/Mac OS X, y obtendrá importantes beneficios de productividad al utilizar Core Data también.

Andrew

Answer 2

Core Data es solo una abstracción de objetos de la base de datos SQLite3. Eso significa que tendrá objetos persistentes fáciles de administrar para operaciones de base de datos estándar. También puede trabajar en modo transaccional y diseñar su estructura de base de datos de datos en XCode creando modelos.

Si no desea crear manualmente su base de datos SQLite3 o métodos persistentes, utilice Core Data.

Answer 3

Uso FMDB para todos mis proyectos que tienen un uso intensivo de "INSERT s" y FMDB no está desactualizado. El último compromiso con Github fue en noviembre pasado. Si usa SQL, le recomiendo usar FMDB.

Datos principales se ajusta al 95% de todos los proyectos, pero si se trata de optimización para ejecutar a una pared. Si desea los beneficios de Core Data (OOP, ...), entonces úselos. Si usted tiene una gran cantidad de una inserción borra con el usuario "WHERE" SQLite (FMDB)

Este POST explicar el apagado y la parte superior sitio para Core Fecha vs. SQLite (FMDB)

Answer 4

CoreData es no simplemente una abstracción de una base de datos SQL. CoreData también hace gestión de gráficos de objetos. CoreData puede hacer cosas que FMDB simplemente no puede hacer.

Como siempre: realmente depende de su caso de uso. Pero en el 99% de los casos, CoreData es la elección correcta.

Si el rendimiento es crítico, aún debe comprender cómo funciona una base de datos. Pero CoreData puede ofrecer ese rendimiento si lo usa de la manera correcta. Pero lleva algo de tiempo aprender. Hay muchas cosas que son triviales en CoreData que serían muy complejas de hacer en FMDB.

Answer 5

Recientemente me embarqué en este viaje y terminé probando los tres. Esto es lo que aprendí:

• Raw Sqlite3
  • de bajo nivel, el pleno acceso a la base de datos. Sin abstracciones Muy detallado: se necesita una gran cantidad de código para hacer cosas muy simples.
• datos básicos
  • muy alto nivel, basado en abstracciones, deberá utilizar la base de datos generada de Apple. Útil para la sincronización de iCloud y la administración de datos simple solo con iOS. Difícil y peligroso acceder directamente a la base de datos, y no debe usarse para bases de datos multiplataforma. Todavía requiere una buena cantidad de código para hacer cosas simples.
• FMDB
  • de alto nivel, muy abstracción amable, pero no forzada. Todavía obtenga acceso completo a la base de datos si la necesita. Proporciona un NSDictionary del resultado con cada elemento escrito automáticamente en la variante mutable del tipo de datos adecuado (p. Ej., Las columnas de texto se devuelven como NSMutableString). Terminé construyendo una clase de contenedor muy simple para abstraerlo aún más, así que tengo una clase auxiliar con funciones estáticas como selectAllFrom:(NSString *)table where:(NSDictionary *)conditions, que devuelve un NSArray de objetos NSDictionary.Es fantástico poder hacer cosas como NSArray *usersNamedJoe = [DBHelper selectAllFrom:@"user" where:@{@"name": @"Joe"}];.

Básicamente, mientras que la base de datos puede ser útil para iOS sólo para simples aplicaciones, cualquiera que esté interesado en el uso de bases de datos multiplataforma debe permanecer lejos, muy lejos de él - Apple no tiene ningún interés en hacer así de fácil , y eso nos muestra.

---

TL; DR:

• No utilizar sqlite3 prima a menos que estés haciendo algo muy trivial.
• Core Data está bien para datos simples solo de iOS, si se siente cómodo con estar bloqueado en él.
• Si quiere control total sobre la base de datos y no está haciendo algo trivial, o está construyendo su aplicación para múltiples plataformas, FMDB es definitivamente el camino a seguir.

Answer 6

Como un nuevo tipo SQL, voy a tirar en mi 0.02:

En base de datos, usted tiene un poco de código "repetitivo" que se necesita para poner en antes de que realmente puede usa tu base de datos Su aplicación necesita al menos uno de estos: 1) Un coordinador de tienda persistente 2) Un contexto de objeto administrado 3) Un objeto administrado. Esto se correlaciona con una entidad, que se correlaciona con una tabla si usa una base de datos SQLite.

Para aprovechar al máximo el marco, debe comprender qué papel desempeñan estos objetos en la gestión de sus datos.

Por otro lado, tenemos SQLite, que, en mi opinión, es mucho más fácil de entender. Para comenzar, necesitará: 1) Una base de datos 2) Una tabla o más (según sus datos) 3) Conocimiento de SQL: un lenguaje flexible con una sintaxis simplista (las consultas SELECT hacen más de lo que originalmente podría creo que lo hacen) 4) Un objeto a través del cual su aplicación se comunica con SQLite.