Android 两个数据库动态比较数据…需要实施建议

所以我想比较两个数据库，一个是只读的，另一个将通过添加只读数据库的内容和删除只读数据库没有的内容来更新自身。本质上是数据的同步

此时，我有两个包含数据的游标（其中一个我转换为arraylist），每个游标中有一个字段用于比较键。这是样品。我觉得我应该搜索相反的内容，就像在只读中搜索一样，而不是在只读中循环并搜索arraylist中的每个项。我希望有某种形式或光标比较，使这更快，更可靠。有什么想法或建议吗

ArrayList<String> addImg = new ArrayList<String>();
ArrayList<String> delImg = new ArrayList<String>();
image_store = m_db.getAllImages();
// this returns an arraylist of strings(can also change to return a cursor)
local_images = img_db.getAllImages();

image_store.moveToFirst();
while(!image_store.isAfterLast()) {
    key = image_store.getString(image_store.getColumnIndexOrThrow("name"));
    // check if stored locally, if not add it to array.
    if(Arrays.binarySearch(local_images, key) == -1) {
        addImg.add( image_store.getString(image_store.getColumnIndexOrThrow("name")));
    } else {
        delImg.add(key);
    }
    image_store.moveToNext();
}
if( !addImg.isEmpty() ) {
    // this will loop through and delete from a cursor generated on another query
    addImages(addImg);
}
if( !delImg.isEmpty() ) {
    // this will loop through and delete from a cursor generated on another query
    delImages(addImg);
}

ArrayList addImg=new ArrayList（）；
ArrayList delImg=新的ArrayList（）；
image_store=m_db.getAllImages（）；
//这将返回字符串的arraylist（也可以更改为返回游标）
local_images=img_db.getAllImages（）；
image_store.moveToFirst（）；
而（！image_store.isAfterLast（））{
key=image\u store.getString（image\u store.getColumnIndexOrThrow（“名称”）；
//检查是否存储在本地，如果没有，则将其添加到数组中。
if（Arrays.binarySearch（local_images，key）=-1）{
addImg.add（image\u store.getString（image\u store.getColumnIndexOrThrow（“名称”））；
}否则{
delImg.add（键）；
}
image_store.moveToNext（）；
}
如果（！addImg.isEmpty（））{
//这将遍历并从另一个查询上生成的游标中删除
addImages（addImg）；
}
如果（！delImg.isEmpty（））{
//这将遍历并从另一个查询上生成的游标中删除
删除图像（addImg）；
}

这取决于您在每个数据库中保存的图像索引的顺序

最好的情况是将它们保持在某种数字或字典顺序。 然后，一个简单的O（N）合并算法将完成这项工作

你是不是把它们保持在同一个顺序，但不是词典？ 然后，您可以使用diff风格的算法来查看需要保留、删除或添加哪些图像

---

如果您没有按任何顺序对它们进行索引，那么您几乎只能使用O（N^2）或O（NlogN）方法。

谢谢您的建议。我每一列都有索引。我更倾向于将这个问题与特定于android的游标联系起来，以及实现这一点的最佳方式是什么。我已经有了一个可行的解决方案，但它需要维护多个临时阵列。