2010-12-13 33 views
3

Ceci est sur iOS. J'ai une base de données de base avec environ 350 000 objets. Les objets (Product) ont deux propriétés: "Barcode" et "Designation". L'utilisateur peut rechercher un objet en cherchant le "code à barres", et la "désignation" doit être renvoyée. Tout fonctionne bien, sauf que c'est lent. Le code que j'utilise est:Accélérer l'extraction des données de base

NSEntityDescription *_product = [NSEntityDescription entityForName:@"Product" inManagedObjectContext:importContext]; 
NSFetchRequest *fetch = [[NSFetchRequest alloc]init]; 

[fetch setEntity:_product]; 
[fetch setPredicate:[NSPredicate predicateWithFormat:@"Barcode == %@",theBarcode]]; 

NSError *error = nil; 
NSArray *results = [importContext executeFetchRequest:fetch error:&error]; 

NSManagedObject *object = [results objectAtIndex:0]; 

Puisque je veux seulement aller chercher un objet, est-il un moyen d'accélérer?

Si je charge chaque objet dans un tableau au démarrage, je reçois un démarrage très lent pour l'application et prend beaucoup de RAM.

Merci d'avance!

EDIT: J'ai ajouté [fetch setFetchLimit: 1]; qui l'accélère un peu. Mais la vitesse devient de plus en plus lente dans la base de données de l'objet.

+0

Je veux juste demander (peut-être que cela aidera) pourquoi charger toutes les données dans un tableau à chaque démarrage? – shannoga

+0

Je ne fais pas ça. Mais j'ai dit, que si je fais ça, alors je vais avoir un démarrage lent :) – Mikael

Répondre

7

L'attribut Barcode est-il indexé?

+0

Merci! Cela a résolu mon problème vraiment bien! Je pensais en fait à l'indexation en revenant du travail le vendredi, mais alors c'était le week-end et j'ai complètement oublié :) Merci encore! – Mikael

4

D'abord, comme l'a écrit @paulbailey, vérifiez si Barcode est indexé. Mais, si vous avez autant d'entrées, et si votre entrée n'a que deux propriétés (code à barres et désignation), et si vous interrogez uniquement du côté du code à barres et que vous retournez le côté désignation, utiliser CoreData peut être excessif. CoreData vous donne beaucoup d'équipements orientés objet avec persistance sur le disque, mais il est bien sûr livré avec une pénalité.

Il est peut-être préférable de supprimer CoreData complètement et d'utiliser directement sqLite. Il y a un joli wrapper léger Objective-C appelé FMDB pour cela, voir here. Si vous voulez coller à CoreData, une façon d'améliorer les choses est d'aller chercher dans le thread d'arrière-plan et d'afficher le résultat dans le thread principal, comme cela est décrit dans this Apple document. De cette façon, l'interface utilisateur ne gèle pas pendant la recherche dans la base de données.

+0

Oui, en fait j'ai commencé le projet en utilisant FMDB mais j'ai fini par utiliser Core Data à la place. Je l'ai fait parce qu'il pourrait y avoir quelques informations supplémentaires à l'application à l'avenir. – Mikael

+0

et l'indexation a fonctionné comme @paulbailey a dit. C'est bon! J'oublie souvent d'indexer les propriétés CoreData moi-même: p – Yuji

0

La raison pour laquelle cela prend plus de temps dans la base de données est que Core Data utilise un algorithme de recherche plutôt terne qui place juste un pointeur sur le premier objet, comprend sa valeur dans le searchitem, place le pointeur sur le prochain et ainsi de suite jusqu'à la comparaison.

Selon votre base de données (listes triées/non triées, structure arborescente, etc.), vous pouvez utiliser des tonnes d'algorithmes de recherche, Quicksearch, Hashsearches, treesearch, etc.

Vous pouvez également envisager de configurer une base de données SQlite à la place, avec de bons cadres avec des algorithmes de recherche intelligents.