Limitaciones de datos principales para iOS

Question

¿Existen limitaciones en los datos principales? p.ej; ¿Cuántas filas máximas puede haber en una tabla/Entidad? ¿Cuántos datos pueden residir en la base de datos?

En general, si algún documento puede describir todo tipo de limitaciones que existen dentro de los datos básicos (para iOS)?

Actualización: w.r.t respuesta dada por @TechZen, mi pregunta fue implícita al hecho de que I/Core Data usará sqlite en el back-end. Pero para aclarar el punto, estoy destinado a usar sqlite y cuando estoy hablando de limitaciones de Core Data, estoy pidiendo indirectamente el límite de sqlite (almacén de base de datos).

Entonces, ¿hay alguna limitación impuesta por los datos principales que no sean el limitations de sqlite cuando hablamos del entorno de iOS?

Answer 1

No hay ninguna limitación lógica en Core Data en sí misma más allá de las impuestas por memoria situacional, espacio en disco, etc. Sin embargo, si usa una tienda SQLite, obtiene default limitations of SQLite itself. Si escribe para iOS, nunca llegará a esos límites .

Realmente, la única limitación práctica que aciertes con los datos centrales proviene de problemas de memoria causados ​​por reading in large blobs p. Ej. tratando de almacenar imágenes o audio en una tienda de SQLite. Eso se puede evitar almacenando los blobs en archivos externos.

Como comentario aparte, le advierto que puedo decir por la forma en que formuló la pregunta, que está pensando en datos erróneos.

Core Data no es un contenedor de objetos para SQL. Core Data no es SQL. Las entidades no son tablas. Los objetos no son filas. Las columnas no son atributos. Core Data es un sistema de gestión de gráficos de objeto que puede o no persistir en el gráfico de objetos y puede o no usar SQL muy detrás de escena para hacerlo. Tratar de pensar en los Datos Básicos en términos de SQL hará que malinterprete completamente los Datos Básicos y resultará en mucho dolor y pérdida de tiempo.

Answer 2

Core Data es un marco de gestión de gráficos de objetos rico y sofisticado capaz de manejar grandes volúmenes de datos. La tienda SQLite puede escalar a bases de datos de tamaño de terabyte con miles de millones de filas, tablas y columnas. A menos que sus entidades mismas tengan atributos muy grandes o grandes cantidades de propiedades, se considera que 10,000 objetos es un tamaño bastante pequeño para un conjunto de datos. Al trabajar con objetos binarios grandes, revise Objetos de datos grandes binarios (BLOB).

objetos binarios grandes (BLOB) de datos

Si la aplicación utiliza Binary Large Object (BLOB), como datos de imagen y sonido, es necesario tener cuidado para minimizar los gastos generales. Si un objeto se considera pequeño o grande depende del uso de una aplicación. Una regla general es que los objetos más pequeños que un megabyte son pequeños o medianos y los que son más grandes que un megabyte son grandes. Algunos desarrolladores han logrado un buen rendimiento con 10 MB BLOB en una base de datos. Por otro lado, si una aplicación tiene millones de filas en una tabla, incluso 128 bytes podrían ser un CLOB (OBject Large Object) que debe normalizarse en una tabla separada.

En general, si necesita almacenar BLOB en una tienda persistente, use una tienda SQLite. Las otras tiendas requieren que el gráfico completo del objeto resida en la memoria, y las escrituras de la tienda sean atómicas (consulte Tipos y comportamientos de tienda persistentes), lo que significa que no manejan de manera eficiente objetos de datos grandes. SQLite puede escalar para manejar bases de datos extremadamente grandes. Si se utiliza correctamente, SQLite proporciona un buen rendimiento para bases de datos de hasta 100 GB, y una sola fila puede contener hasta 1 GB (aunque, por supuesto, leer 1GB de datos en la memoria es una operación costosa sin importar cuán eficiente sea el repositorio).

Un BLOB a menudo representa un atributo de una entidad; por ejemplo, una fotografía puede ser un atributo de una entidad Empleado. Para BLOB de pequeño a moderado (y CLOB), cree una entidad separada para los datos y cree una relación uno a uno en lugar del atributo. Por ejemplo, puede crear entidades de Empleado y Fotografía con una relación uno a uno entre ellas, donde la relación de Empleado a Fotografía reemplaza el atributo de fotografía del Empleado. Este patrón maximiza los beneficios de fallas de objetos (vea Fallas y Uniquing). Cualquier fotografía dada solo se recupera si realmente es necesaria (si la relación se cruza).

Es mejor, sin embargo, si puede almacenar BLOB como recursos en el sistema de archivos y mantener enlaces (como URL o rutas) a esos recursos. Luego puede cargar un BLOB cuando sea necesario.