Quoi de plus cher? requêtes de base de données constantes ou tout d'abord charger tout dans un tableau d'objets?

Question

Je développe une application qui, au démarrage, configure un curseur de base de données pour afficher les valeurs dans une liste. Au cours de l'application, les données d'exécution dans la base de données sont mises à jour et je mets constamment à jour le curseur. Il fonctionne un peu mais parfois le curseur est en retard sur les mises à jour de la base de données, affichant ainsi les anciennes données dans la liste jusqu'au bout de quelques secondes.

Serait-il plus efficace si je charge toutes les données (environ 10-20 ensembles d'environ 20 chaînes et ints chacune) dans un tableau d'objets au démarrage et n'écrivais à la base de données qu'à la fermeture?

Quel est le coût des requêtes de base de données par rapport à la création de tableaux d'objets?

Merci pour votre aide!

Answer 1

Cela dépend de votre définition de "cher". Si vous faites référence à la bande passante, les requêtes constantes sont plus coûteuses. Chaque requête à une base de données distante se produit sur un ordre de millisecondes tandis qu'une requête à un objet en mémoire est sur un ordre de nanosecondes. Si «cher» signifie une latence immédiate du réseau de réduction de la vitesse de traitement, le chargement en mémoire sera plus coûteux car le système passe en revue plus d'informations au moment de l'action.

Dans votre cas, puisque vous traitez avec Android, je dirais que votre meilleur pari est une combinaison des deux. Vous voudrez charger autant de données que vous aurez besoin de travailler à n'importe quel moment. Vous pouvez envisager de créer éventuellement des listes d'adjacence pour les données si cela peut aider à la récupération des données. Avec un bon système de liste d'adjacence, vous pouvez interroger les données dont vous aurez bientôt besoin tout en travaillant sur les données que vous avez maintenant (cela permet de réduire l'impact de la latence du réseau). En ce qui concerne la partie de mise à jour, à moins que vous n'ayez à mettre en file d'attente vos modifications et à les télécharger de manière asynchrone, vous ne pouvez pas vraiment éviter cette latence. C'est juste comment le réseau fonctionne. Toutefois, si vous pouvez travailler de manière asynchrone avec l'interface, vous pouvez mettre en file d'attente la modification et demander à la mise à jour de se produire physiquement au niveau de la base de données pendant que l'utilisateur passe à la tâche suivante.

Answer 2

À moins que vous ne parliez beaucoup de données (millions de lignes), le coût (en UC) de création d'objets en mémoire pour les stocker sera minime par rapport au temps d'exécution d'une requête DB.