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

sqlite ios (6)

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 otros, pero estos 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 debería 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?

Ankit,

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

Aquí está la forma larga:

Si bien puede utilizar muchos criterios para elegir entre datos básicos, un ORM (FMDB) o llamadas directas a sqlite, el costo real de esta elección proviene de su tiempo para usarlo, el soporte de Apple y el apalancamiento de otros proyectos. (RESTKit, que asigna 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 centrales. ¿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 traes una base de datos y un esquema SQLite grandes y complejos 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 creía).

Core Data tiene una gran repercusión en el rendimiento. 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 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 son dispositivos móviles en las hojas de Internet, generalmente es de un 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, has tenido que utilizar "todo" para usar Objective-C en iOS / Mac OS X, también obtendrás importantes beneficios de productividad al utilizar Core Data.

Andrés

Como un nuevo tipo SQL, voy a lanzar mi .02:

En Core Data, tiene un poco de código "repetitivo" que debe incluir antes de poder usar su base de datos. Su aplicación necesita al menos uno de estos: 1) Un coordinador de tienda persistente 2) Un contexto de objeto gestionado 3) Un objeto gestionado. 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 empezar, 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 pensar que hacen ) 4) Un objeto a través del cual su aplicación se comunica con SQLite.

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.

CoreData no es solo 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 tu 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.

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

Raw sqlite3
- Bajo nivel, acceso completo a la base de datos. Sin abstracciones Muy detallado: se necesita una gran cantidad de código para hacer cosas muy simples.
Datos principales
- Muy alto nivel, basado en abstracciones, DEBE usar 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 amigable pero no forzada. Todavía obtenga acceso completo a la base de datos si la necesita. Proporciona una NSDictionary del resultado con cada elemento encasillado automáticamente en la variante mutable del tipo de datos adecuado (por ejemplo, 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, aunque Core Data puede ser útil para aplicaciones simples solo de iOS, cualquiera que esté interesado en utilizar bases de datos multiplataforma debería mantenerse alejado, Apple no tiene interés en facilitarlo, y eso se nota.

TL; DR:

No use sqlite3 sin formato a menos que esté haciendo algo extremadamente trivial.
Core Data está bien para datos simples solo de iOS, si te sientes cómodo con estar bloqueado en él.
Si desea un control total sobre la base de datos y no está haciendo algo trivial, o si está creando su aplicación para múltiples plataformas, FMDB es definitivamente el camino a seguir.

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.

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

Este POST explica el sitio superior e inferior para Core Date vs. Sqlite (FMDB)