Core Data vs. SQLite 3 [zamknięty]

Znam już relacyjne bazy danych i korzystałem z SQLite (i innych baz danych) w przeszłości. Jednak Core Data ma pewien urok, więc zastanawiam się, czy poświęcić trochę czasu, aby nauczyć się go do wykorzystania w mojej następnej aplikacji.

Czy korzystanie z podstawowych danych jest większe niż w przypadku SQLite lub odwrotnie? Jakie są zalety / wady każdego z nich?

Trudno mi uzasadnić koszt uczenia się podstawowych danych, gdy Apple nie używa ich do wielu swoich flagowych aplikacji, takich jak Mail.app lub iPhoto.app - zamiast tego wybiera bazy danych SQLite. SQLite jest również szeroko stosowany na iPhonie.

Czy osoby znające się na używaniu obu mogą komentować swoje doświadczenia? Być może, podobnie jak w przypadku większości rzeczy, pytanie jest głębsze niż używanie jednej nad drugą?

Chociaż Core Data jest potomkiem Apple Enterprise Framework Framework , mapera relacyjno-obiektowego (ORM), który był / jest ściśle powiązany z relacyjnym zapleczem, Core Data nie jest ORM. W rzeczywistości jest to struktura zarządzania grafem obiektowym. Zarządza potencjalnie bardzo dużym wykresem obiektów, umożliwiając aplikacji pracę z wykresem, który nie zmieściłby się całkowicie w pamięci, powodując błędy obiektów wchodzących i wychodzących z pamięci w razie potrzeby. Podstawowe dane zarządzają również ograniczeniami właściwości i relacji oraz zachowują spójność referencji (np. Utrzymanie spójności łączy do przodu i do tyłu, gdy obiekty są dodawane / usuwane do / z relacji). Core Data jest zatem idealną platformą do budowania komponentu „modelowego” architektury MVC.

Aby realizować swoje zarządzanie wykres Core danych zdarza się używać SQLite jako magazyn na dysku. To mógł być realizowany przy użyciu innej relacyjnej bazy danych lub nawet non-relacyjnej bazy danych takie jak CouchDB . Jak zauważyli inni, Core Data może również wykorzystywać XML lub format binarny lub zapisany przez użytkownika format atomowy jako backend (chociaż te opcje wymagają, aby cały wykres obiektu zmieścił się w pamięci). Jeśli interesuje Cię, w jaki sposób Core Data jest implementowany na backendzie SQLite, możesz sprawdzić OmniDataObjects Framework OmniGroup , implementację open source podzbioru API Core Data. BaseTen ramy jest również implementacja API Rdzeń danych przy użyciu PostgreSQL jako backend.

Ponieważ dane podstawowe nie mają być ORM dla SQLite, nie mogą odczytać dowolnego schematu SQLite. I odwrotnie, nie powinieneś polegać na możliwości odczytywania magazynów danych SQLite w Core Data za pomocą innych narzędzi SQLite; schemat jest szczegółem implementacji, który może ulec zmianie.

Tak więc nie ma tak naprawdę żadnego konfliktu między bezpośrednim użyciem Core Data lub SQLite. Jeśli chcesz mieć relacyjną bazę danych, użyj SQLite (bezpośrednio lub za pośrednictwem jednego z owijek Objective-C, takich jak FMDB ) lub serwera relacyjnych baz danych. Jednak nadal możesz chcieć nauczyć się podstawowych danych do wykorzystania jako struktura zarządzania grafami obiektowymi. W połączeniu z klasami kontrolerów Apple i widżetami widoku zgodnymi z wiązaniem klucz-wartość możesz zaimplementować pełną architekturę MVC z bardzo małym kodem.

A dzięki iOS 5.0 zyskujesz dodatkową korzyść z bezpłatnego korzystania z synchronizacji plików iCloud, jeśli korzystasz z Core Data. Jeśli używasz SQLite bezpośrednio, trzeba będzie dużo ręcznego majsterkowania i implementacji, aby zsynchronizować go z iCloud.

Core Data to nie tyle silnik bazy danych, co API, który wyodrębnia rzeczywisty magazyn danych. Możesz nakazać Core Data zapisać jako bazę danych sqlite, plist, plik binarny lub nawet niestandardowy typ magazynu danych.

Polecam naukę podstawowych danych, ponieważ jest to doskonały zasób, który znacznie przyspiesza wiele etapów rozwoju aplikacji kakao.

SQLite jest jednym z formatów baz danych dla podstawowych danych. Korzystając z Core Data, uzyskujesz lepszą integrację z resztą API Cocoa.