Diseño de modelo de CoreData: ¿El uso excesivo de NSFetchRequest es un síntoma de un modelo mal diseñado?

Question

Los objetos de Datos centrales se pueden recuperar utilizando un NSFetchRequest o siguiendo las relaciones con otros objetos en el gráfico. ¿Es justo decir que en un modelo bien diseñado contendrá relaciones suficientes (y propiedades recuperadas) de tal manera que el uso de NSFetchRequests se mantenga al mínimo?

El argumento del contador es que en iOS existe NSFetchedRequestController. Presumiblemente, si Apple creía que las relaciones y las propiedades obtenidas proporcionaron un rendimiento satisfactorio con el caché/fallas existentes, no habrían creado NSFetchedRequestController.

Hay casos en que el uso de un NSFetchRequest es superior ya que Core Data puede hacer todo el trabajo dentro de SQLite. Un ejemplo sería ir a buscar valores agregados.

¿Alguna idea de esto? He echado un vistazo al Core Data Programming Guide. Hay consejos relevantes en las secciones 'Obtención de objetos administrados' y 'Rendimiento de datos básicos', pero nada que sugiera con fuerza las relaciones sobre las solicitudes de recuperación o viceversa.

Answer 1

La regla general es que cuanto más simple es el modelo de datos, mejor funciona, mientras que cuanto más complejo es el modelo de datos, mejores son las relaciones.

Por ejemplo, si su modelo de datos tiene una única entidad sin relaciones, una recuperación funcionará mejor para encontrar los objetos gestionados aislados. Si tiene un modelo de datos con una docena de entidades, todas con dos o más relaciones, entonces usará las relaciones en gran medida.

Answer 2

Diría que las relaciones y NSFetchRequest tienen sus fortalezas y debilidades. Como desarrollador, debe saber cuándo es apropiado usar uno u otro. Por ejemplo, adoptar este modelo:

-------------- 1   * ------------ 
| Department |<------------->>| Employee | 
--------------    ------------ 
| name  |    | name  | 
--------------    | age  | 
           | salary | 
           ------------ 

Si desea recuperar todos los empleados que pertenecen a un departamento en particular, entonces es conveniente seguir la relación 'department.employees'. No es apropiado crear una NSFetchRequest para la entidad Employee con el predicado 'department == xxxx'.

Por el contrario, si desea encontrar empleados para un departamento particular con un salario> x, entonces es apropiado utilizar una NSFetchRequest con un predicado como 'departamento == xxxxx Y salario> x'. No es apropiado recuperar a todos los empleados que utilizan la relación department.employees y luego iterar sobre ellos en un bucle para encontrar a los que más ganan.

En resumen, las relaciones o NSFetchRequests no son intrínsecamente "buenas" o "malas". Solo úselos apropiadamente. Usa relaciones para navegar tu gráfico de objetos. Use NSFetchRequest para realizar búsquedas de subconjuntos o donde necesite la flexibilidad de devolver resultados como diccionarios o necesite usar NSExpressions.

Editar para agregar:

Una gran cantidad de NSFetchRequests esparcidos por todo su código es un signo de un mal diseño. Siempre encapsulo solicitudes de datos en clases NSManagedObject personalizadas y trato de no tener ninguna llamada Core Data en el código de vista/vista del controlador.

Las propiedades extraídas son, supongo, una forma de lograr lo mismo. Prefiero crear un NSFetchRequest en el código en lugar de usar el editor de Core Data para hacerlo. Es mucho más flexible, pero en ambos sentidos es lo mismo en realidad.

Answer 3

Cuando diseñe un modelo en coredatos, debe tener en cuenta que si tiene 1, 2 o n relaciones en el modo, l indica que su gráfico de objetos se comportará como la base de datos SQL porque solo obtendrá el principal filas, excepto la necesidad explícita de su aplicación en la primera solicitud de todos los objetos. De hecho, Apple recomienda dividir su modelo en las relaciones por motivos de rendimiento, de modo que cuando su modelo falla en una búsqueda en ese momento obtendrá el resto. El único aspecto que debe importar son las reglas de eliminación (nulo, cascada ...) porque una regla de eliminación mal diseñada puede bloquearse o afectar el rendimiento. Confíe en mí, nunca he visto nada tan eficiente como los datos centrales. Haga un modelo fuerte y los datos básicos harán el resto.

Una de mis aplicaciones (Mariette) utilizan datos básicos y otro (billingfiles) utilizan SQL