iOS - 核心数据和服务器数据库同步最佳实践 [英] iOS - Core Data and Server Database Synchronization Best Practices

查看:165
本文介绍了iOS - 核心数据和服务器数据库同步最佳实践的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我开始为大规模应用程序设置核心数据模型,并希望在服务器数据库和离线功能方面对适当的同步方法/技术提供一些反馈。



我使用PHP和mySQL作为我的网络服务器/数据库。



我已经知道如何连接,接收数据,存储到核心数据等。我正在寻找更多的帮助,以跟踪数据更改的方法和特定实例:



A)确保应用和服务器在在线和离线使用期间同步离线活动将被推回一次在线)。
B)优化将数据保存到应用程序的速度。



我的主要问题是: b

什么是检查应用程序中的新/更新数据仍需要同步(离线使用后)的最佳方法?



(即在我的所有核心数据实体中,我都设置了一个BOOL类型的'isSynchronized'属性,然后一旦成功提交并且响应从服务器发回,更新为YES)。这是最好的方法吗?



什么是最佳方式来优化从服务器到核心数据的数据保存速度?



(即,我如何只更新Core Data中比服务器数据库上的数据更新的数据,而不是迭代每个实体,只更新每次)?可以不添加用于跟踪更新时间戳到EVERY表的服务器数据库列吗?



同样,我已经知道如何下载数据并将其存储到Core Data只需寻找一些帮助,确保最佳实践,确保同步的应用程序和服务器数据库,同时确保优化的处理时间。

解决方案



手机搜索自从上次更改以来发生更改的所有内容的最后一次修改时间戳记。电话上的核心数据记录和服务器上的mysql表格。同步并将其与上一次同步的时间戳一起发送到服务器,并且服务器以自提供的同步时间戳之后结束时已更改的所有内容进行响应。



当大量记录更改时,性能是一个问题。我做一个背景NSOpeartion的同步,它有自己的管理对象上下文。当后台线程完成对它的管理对象上下文的更改时,有一个API用于将所有更改合并到主线程的受管对象上下文中 - 这可以被配置为如果有任何冲突导致的所有更改用户在同步正在进行时更改数据。在这种情况下,我只需等待几秒钟,然后再次尝试进行同步。



在较旧的硬件上,即使经过多次优化,也必须完全中止同步用户开始在应用程序中做的东西。它只是使用太多的系统资源。我认为更多的现代iOS设备可能足够快,你不需要这样做了。



(顺便说一句,当我说很多记录已经改变我的意思是要更新或插入到手机上的大约30,000行)


I am starting to setup the core data model for a large scale app, and was hoping for some feedback on proper synchronization methods/techniques when it comes to server database and offline capabilities.

I use PHP and mySQL for my web server / database.

I already know how to connect, receive data, store to core data, etc etc. I am looking more for help with the methodologies and particular instances of tracking data changes to:

A) Ensure the app and server are in sync during online and offline use (i.e. offline activity will get pushed up once back online). B) Optimize the speed of saving data to the app.

My main questions are:

What is the best way to check what new/updated data in the app still needs to be synchronized (after offline use)?

(i.e. In all my Core Data Entities I put a 'isSynchronized' attribute of BOOL type. Then update to 'YES' once successfully submitted and response is sent back from server). Is this the best way?

What is the best way to optimize speed of saving data from server to core data?

(i.e. How can I only update data in Core Data that is older than what is on server database without iterating through each entity and just updating every single time)? Is it possible without adding a server database column for tracking update timestamps to EVERY table?

Again, I already know how to download data and store it to Core Data, I am just looking for some help with best practices in ensuring synchronization across app and server databases while ensuring optimized processing time.

解决方案

I store a last modified timestamp in the database on both the core data records on the phone, and the mysql tables on the server.

The phone searches for everything that has changed since the last sync and sends it up to the server along with a timestamp of the last sync, and the server responds with everything that has changed on it's end since the provided sync timestamp.

Performance is an issue when a lot of records have changed. I do the sync on a background NSOpeartion which has it's own managed object context. When the background thread has finished making changes to it's managed object context, there is an API for merging all of the changes into the main thread's managed object context - which can be configured to simply throw away all the changes if there are any conflicts caused by the user changing data while the sync is going on. In that case, I just wait a few seconds and then try doing a sync again.

On older hardware even after many optimisations it was necessary to abort the sync entirely if the user starts doing stuff in the app. It was simply using too many system resources. I think more modern iOS devices are probably fast enough you don't need to do that anymore.

(by the way, when I said "a lot of records have changed" I meant 30,000 or so rows being updated or inserted on the phone)

这篇关于iOS - 核心数据和服务器数据库同步最佳实践的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆