① sqlite版本升級做數據遷移怎麼弄啊,求助
直接在現有基礎上alter table就可以修改資料庫結構了。 查看原帖>>
② android上有PropertyUtils的替代品嗎
Realm是一個開源的面向對象移動資料庫。上個月，Realm的Android版本發布了，比iOS版本晚了三個月。
我們之前已經報道過，Realm沒有使用SQLite作為它的引擎，而是用C++寫了自己的引擎，他們的目標是提供一個聚焦移動領域的SQLite的替代者。現在它的Android版本已經發布了。
當前Android上的Realm的API和iOS版本有點不同，這也反映了Objective C和Java的差別。Java版本的API有更高的強類型（strong-typed）要求，也更連貫（fluent）。
比如，在iOS上，查詢是通過靜態方法如"objectWhere"來進行的，這將返回一個RLMArray。這里的謂詞都是基於字元串的。以下就是基於Object C的查詢方法：
RLMArray *tanDogs = [Dog objectsWhere:@"color = 'tan' AND name BEGINSWITH 'B'"];
另一方面，在Android下進行相同的查詢卻是這樣的：
RealmResults<Dog> tanDogs = realm.where(Dog.class)
.equalTo("color", "tan")
.beginsWith("name", "B")
.findAll();
當然，這有可能會被一種跨iOS、Android和其他平台的文本查詢語言所替代。Tim Anglade是Realm的產品主管，他在一封郵件中指出，未來API的發展方向很大程度取決於社區的反饋。
雖然Realm是一個面向對象的資料庫，但它和其他同類產品還是有一些明顯的不同。Tim解釋道，當它用原生對象格式（native object format）來存儲數據時，這些對象不會帶著其語言特有的格式原封不動地存在磁碟上，而是通過C++引擎存儲在一個全局的表中。這使得Realm可以通過各種語言來訪問數據，還包括各種即時查詢（adhoc query）。
相比關系資料庫，這種混合了對象和表的方式的優勢在於它使圖查詢（graph query）更高效——甚至在相對老舊的智能手機上，查詢深度嵌套的對象圖也不會影響系統反應速度。Realm發布的基準測試（benchmark）結果稱，在普通操作上，Realm的速度最快要達到原始的SQLite的10倍。
如果你現在有一個應用程序使用CoreData（iOS上）或SQLite（Android上），並且想遷移到Realm，肯定有一些事要做。這不是隨便拿來就能用的——Tim解釋說，CoreData和SQLite傾向於使用一種非常標准化的形式，這種做法在Realm上行不通。你最好從對象的角度重新思考你的模式（schema）和模型（model）。
一旦你修改了你的模式，使之適用於Realm，接下來把現有數據從CoreData/SQLite遷移過來就簡單了。只要配置一次遷移操作（從Realm資料庫版本0到版本1），在遷移過程中，把你的SQLite數據載入到Realm對象中並保存它們。
或者，如果你的數據保存在遠程伺服器上，你可以從頭新建Realm資料庫。
在採用Realm之前，必須要考慮到它是一個最前沿的軟體，這意味著將來它的API有可能做出和以前不兼容的修改。
你可以通過Android版本的Realm來了解更多，或者查看Github上的代碼。
③ iOS 開發如果涉及數據和表的持久化，Core Data 比 SQLite 更好嗎
這兩個東西我都用過，兩者都能實現對資料庫的操作，功能上需求都能滿足。
先前在公司實習的時候，原先項目中用的是SQLite，感覺操作很直接。如果先前有一點資料庫和SQL基礎的話，寫起來會感覺很親切，都是一些資料庫操作的語句。但是當操作變多之後，語句越來越多，就很煩，代碼比較多，看起來也會混亂一些。
後來新項目中嘗試了CoreData，因為蘋果一直在推這個東西。CoreData用起來比直接sql語句方便許多，而且很適合進行代碼封裝、重構。其實後來在用CoreData的時候，參照RestKit的ObjectMapping和CoreData部分對其進行了少量封裝，使得CoreData用起來非常方便。例如：添加一條User數據
User *user = [User object];
user.name = @"example";
[objectStore save];
後來做開發一直都在用CoreData，主要是我覺得用起來太方便了，代碼能夠精簡許多。另外，
App升級之後資料庫欄位或者表有更改會導致crash，CoreData的版本管理和數據遷移變得非常有用，手動寫sql語句操作還是麻煩一些。
CoreData不光能操縱SQLite，CoreData和iCloud的結合也很好，如果有這方面需求的話優先考慮CoreData。
CoreData並不是直接操縱資料庫，比如：使用CoreData時不能設置資料庫的主鍵，目前仍需要手動操作。
效率上其實跑程序時感覺不出來，畢竟手機上的數據不能跟網站的數據和訪問量相提並論。
總的來說，個人比較喜歡用CoreData，因為自己比較熟悉，使用起來也非常方便。
PS：既然你一直在CoreData，就應該堅持用下去，除非是真的碰到很致命的無法解決問題。中途換掉既有的自己熟悉的東西，費時費力，實際用起來沒區別，得不償失。
轉載
④ 求助CoreData中是否有表對表數據遷移的方法,或者遷移表中部分數據
有幾種思路：
1.寫個導入導出程序
2.利用資料庫自帶的導入導出工具（大型資料庫一般都有的）
3.sql腳本導入導出
⑤ ios 裡面coredata怎麼使用
搜扣丁學堂，有很多關於iOS中的CoreData的講解： Core Data數據持久化是對SQLite的一個升級，它是ios集成的，在說Core Data之前，我們先說說在CoreData中使用的幾個類。 （1）NSManagedObjectModel(被管理的對象模型) 相當於實體，不過它包含 了實體間的關系 (2)NSManagedObjectContext(被管理的對象上下文) 操作實際內容 作用：插入數據 查詢 更新 刪除 （3）NSPersistentStoreCoordinator(持久化存儲助理) 相當於資料庫的連接器 (4)NSFetchRequest(獲取數據的請求) 相當於查詢語句 (5)NSPredicate(相當於查詢條件) (6)NSEntityDescription(實體結構) (7)後綴名為.xcdatamodel的包 裡面的.xcdatamodel文件，用數據模型編輯器編輯 編譯後為.momd或.mom文件，這就是為什麼文件中沒有這個東西，而我們的程序中用到這個東西而不會報錯的原因
⑥ 如何使用Core Data
預載入/引入數據
那麼我們究竟怎樣把數據存儲進Core Data資料庫呢？目前有兩種比較好的選擇。
在App啟動的時候從外部文件引入數據，就是在程序開始運行的時候從外部的資源，比如SQLite資料庫或者XML文件中，引入數據。
提供一個已經製作完成的SQLite資料庫，首先製作一個像上次的教程說的那樣的資料庫模型，之後在這個模型中填充數據，填充數據的方式是使用一個utility app，這個utility app可以是一個使用Core Data API填充資料庫的Mac或者iOS app，也可以是一些直接填充資料庫的程序。一旦資料庫被填充之後，你就可以在沒有已存在的資料庫的情況下設置這個資料庫未使用的默認資料庫。
在這個教程中，我們會通過第二種，為大家展示如何使用一個簡單的utility app來預載入一個已經裝在好的Core Data資料庫，以便讓你的app使用。
第一步
我們在iOS上使用Core Data的方法的基礎和我們在Mac OS X上使用的是一致的，他們使用同樣的模型和類。
這一為我們可以寫一個MAC OS X上的簡單的console程序，來從數據源引入數據，再把這個資料庫的資料庫拿來給我們的iOS程序來用，不錯吧？
我們來試試，首先打開Xcode，在 Mac OSX類中的Application中使用Command Line Tool 的模板。
我們就用 「CoreDataTutorial2」 作為工程的名字吧，記得使用「Core Data」 和 「Use Automatic Reference Counting」 。
完成創建之後，選擇 「CoreDataTutorial2.xcdatamodeld」 徹底刪除之。
⑦ IOS 存儲方式（PList、NSUserDefaults、歸檔、CoreData、資料庫、文件）
iOS開發，plist文件讀寫那些事 - (jianshu.com)
NSUserDefaults存儲輕量級 的本地數據 ，比如要保存一個登陸界面的數據，用戶名、密碼之類的。
支持的數據類型有 NSString、 NSNumber、NSInteger、NSFloat、BOOL、NSArray、NSDictionary、NSDate、 等系統定義的數據類型。
用NSUserDefaults存儲的數據下次程序運行的時候依然存在 .它的數據存儲在應用程序內置的一個plist文件里, 在/Library/Prefereces沙盒路徑下.
NSUserDefaults是定時把緩存中的數據寫入磁碟的，而不是即時寫入，為了防止在寫完NSUserDefaults後程序退出導致的數據丟失，可以在寫入數據後使用synchronize強制立即將數據寫入磁碟：
使用NSKeyedArchiver 對數據進行 歸檔 反歸檔（將自定義類型轉換為NSData類型:）
NSuserDefaults 的坑
iOS 最終，我還是決定放棄使用NSUserDefaults了 - (jianshu.io)
歸檔： ，就是將數據寫到一個文件裡面去。一般我們的應用的變數常量之類的數據都是在內存裡面的，只要APP關閉，這些數據都會丟失。但是把數據存儲到文件裡面去，就能將數據保存到本地磁碟裡面（目前iOS基本就是在沙盒裡面操作了），不管是APP關閉還是重啟設備，下次啟動APP的時候都能夠讀出來。
解檔： (別人也叫反歸檔)，就是將數據從文件裡面讀取出來。在程序裡面使用。
【iOS】數據持久化：使用NSKeyedArchiver進行數據歸檔 - (jianshu.com)
iOS 開發Core Data使用方法 – 技術狗 (jishudog.com)
IOS 開發文件操作——NSFileManager - 星語海藍 - 博客園 (cnblogs.com)
(15條消息) iOS文件操作_你有故事，我囿酒-CSDN博客
參考：
iOS開發 - 關於 NSUserDefaults 的使用 - (jianshu.com)
⑧ iOS 開發如果涉及數據和表的持久化，Core Data 比 SQLite 更好嗎
首先，coredata和sqlite的概念不同，core為對象周期管理，而sqlite為dbms。
下面的討論以使用core data來做數據持久化並使用sqlite做backend存儲的情況為前提。
使用方便性。實際上，一個成熟的工程中一定是對數據持久化進行了封裝的，因此底層使用的到底是core data還是sqlite，不應該被業務邏輯開發者關心。因此，即使習慣寫SQL查詢的人，也應該避免在業務邏輯中直接編寫SQL語句。
存儲性能，在寫入性能上，因為都是使用的sqlite格式作為磁碟存儲格式，因此其性能是一樣的，如果你覺得用core data寫的慢，很可能是你用sqlite的時候寫的每條數據的內容沒有core data時多，或者是你批量寫入的時候每寫入一條就調用了一次save。
查詢性能，core data因為要兼容多種後端格式，因此查詢時，其可用的語句比直接使用sqlite少，因此有些fetch實際上不是在sqlite中執行的。但這樣未必會降低查詢效率。因為iPhone的flash memory速度還是很快的。我的經驗是大部分時候，在內存不是很緊張時，直接fetch一個entity的所有數據然後在內存中做filter往往比使用predicate在fetch時過濾更快。如果你覺的查詢慢，很可能是查詢方式有問題，可以把core data的debug模式打開，看一下到底執行了多少SQL語句，相信其中大部分是可以通過改寫core data的調用方式避免的。
core data的一個比較大的痛點是多人合作開發的時候，管理coredata的模型需要很小心，尤其是合並的時候，他的data model是XML格式的，手動resolve比較煩心。
core data還有其他sql所不具備的優點，比如對undo的支持，多個context實現sketchbook類似的功能。為ManagedObject優化的row cash等。
另外core data是支持多線程的，但需要thread confinement的方式實現,使用了多線程之後可以最大化的防止阻塞主線程