Dati principali VS Sqlite o FMDB ....?

Question

Ora questo potrebbe sembrare un thread duplicato, ma la mia domanda è che ho letto un sacco di domande come .. Core Data vs SQLite 3 e altri, ma questi hanno 2-3 anni. Ho anche letto che FMDB è stato sviluppato poiché i dati principali non erano supportati su iOS, quindi non dovrebbe più essere usato. E d'altra parte ho letto che non si dovrebbero usare i dati di base come database.

Quindi sono seriamente confuso, se dovrei utilizzare i dati di base per l'archiviazione degli oggetti o non. Intendo su quale base dovrei decidere quale usare? Ci sono delle linee guida fornite da Apple o da qualcun altro .. o è qualcosa che verrà da me con il tempo?

Answer 1

Ankit,

Ecco il tl; dr skinny: usa Core Data.

Ecco la forma lunga:

Mentre si potrebbe utilizzare molti criteri per scegliere tra Core Data, un ORM (FMDB) o chiamate SQLite dirette, il costo reale di questa scelta viene dal vostro tempo di usarla, Apple supporto e leva da altri progetti. (RESTKit, che associa i servizi REST a Core Data, è popolare in questi giorni.)

Quindi, una grande percentuale del tempo, diciamo 90 +% (una statistica composta), la risposta su iOS sarà utilizzata Dati principali. Perché? Una volta capito e sviluppato alcuni piccoli metodi di supporto, Core Data ti tiene in un mondo informatico coerente: il grafico dell'oggetto Objective-C. Core Data ti insegnerà come utilizzare un linguaggio dinamico che aiuterà ogni altro aspetto della tua programmazione iOS. Quindi, sei più produttivo. Non combattere il quadro.

Se si trasferisce uno schema SQLite grande e complesso di database & da un'altra app, potrebbe essere conveniente utilizzare FMDB o SQLite. Ma ne dubito. Il tempo impiegato per scrivere una semplice app da riga di comando basata su Mac per migrare il DB in un DB di dati di base è un compito semplice e finito. È quasi garantito che si debba riscrivere la maggior parte della logica aziendale in Objective-C. (Sì, C++ e Objective-C++ sono entrambe buone tecnologie. La tua logica di business del database è stata sintonizzata per funzionare su un dispositivo con memoria limitata? Non lo credevo.)

I dati di base ottengono un abbandono alle prestazioni. È davvero abbastanza veloce Devi solo usarlo diversamente da come usi un DB. In particolare, si esegue quasi sempre il recupero dei dati dall'archivio e si raffina utilizzando i predicati direttamente sui vari set e array.Sui dispositivi iOS, dove il flash è sorprendentemente lento, questa strategia di over-fetch è particolarmente efficace. In realtà hai molta RAM su questi dispositivi, usala per ottenere prestazioni. (Sì, so che questa è un'apparente contraddizione con la mia precedente bussata alla logica di business portatile, ma in realtà il codice trasferito da un ambiente desktop o server ha così tante ipotesi implicite sulla velocità del disco, sulla quantità di memoria e sulla realtà di una VM con un backing store, non funzionerà bene su un dispositivo a batteria con memoria limitata con un modello di memoria funky. [Non funzionerà molto bene sui dispositivi Android.]) Inoltre denormalizzi i dati per semplificare visualizzandolo in vari widget dell'interfaccia utente di iOS e Mac OS X. Ci sono alcune applicazioni in cui Core Data sarà più lento di un DB SQLite equivalente. Quelli sono stati dettagliati altrove. L'unica importante affermazione è che le attività in cui gli ID sono definiti dai database upstream raggiungono le prestazioni di Core Data. Ma può essere in qualche modo mitigato dall'indicizzazione giudiziosa e dalla trascuratezza.

La cosa da ricordare sui dispositivi mobili è che le dimensioni del database, poiché si tratta di dispositivi mobili sulle foglie di Internet, sono generalmente di dimensioni modeste. Quindi, le prestazioni sono più facili da raggiungere. Molte lezioni dal mondo dei server potrebbero non essere applicabili a questo mondo mobile, alimentato a batteria.

In altre parole, è necessario andare "all in" per utilizzare Objective-C su iOS/Mac OS X, inoltre si otterranno importanti vantaggi in termini di produttività dall'utilizzo di Core Data.

Andrew

Answer 2

Core Data è solo un'astrazione dell'oggetto del database SQLite3. Ciò significa che gli oggetti persistenti saranno facili da gestire per le operazioni standard del database. Puoi anche lavorare in una modalità transazionale e progettare la struttura del tuo database dati principale in XCode creando modelli.

Se non si desidera creare manualmente il database SQLite3 oi metodi persistenti utilizzano i dati principali.

Answer 3

Io uso FMDB per tutti i miei progetti che hanno un uso intenso di "INSERT s" e FMDB non è aggiornato. L'ultimo impegno su Github era lo scorso novembre. Se vai con SQL ti consiglio di usare FMDB.

I dati di base si adattano al 95% di tutti i progetti, ma se si tratta di ottimizzazione per correre a un muro. Se vuoi i benefici di Core Data (OOP, ...) usalo. Se si dispone di un sacco di Inserire una elimina con "WHERE" utente Sqlite (FMDB)

Questa POST spiegare il largo e sito principale per core Data vs. Sqlite (FMDB)

Answer 4

CoreData è non solo un'astrazione di un database SQL. CoreData esegue anche la gestione del grafo degli oggetti. CoreData può fare cose che FMDB semplicemente non può fare.

Come sempre: dipende davvero dal tuo caso d'uso. Ma nel 99% dei casi CoreData è la scelta giusta.

Se la prestazione è critica, è ancora necessario capire come funziona un database. Ma CoreData è in grado di fornire tali prestazioni se lo si utilizza nel modo giusto. Ma ci vuole un po 'di tempo per imparare. Ci sono molte cose che sono banali da fare in CoreData che sarebbero molto complesse da fare in FMDB.

Answer 5

Recentemente ho intrapreso questo viaggio da solo, e ho finito per provarli tutti e tre. Ecco cosa ho imparato:

• Raw sqlite3
  • di basso livello, pieno accesso al database. Nessuna astrazione. Molto prolisso - ci vuole una buona dose di codice per fare cose molto semplici.
• Core Data
  • molto alto livello, costruito su astrazioni, deve utilizzare un database generato di Apple. Utile per la sincronizzazione di iCloud e la semplice gestione dei dati solo su iOS. Difficile e pericoloso accedere direttamente al database e non dovrebbe essere utilizzato per database multipiattaforma. Prende ancora una buona quantità di codice per fare cose semplici.
• FMDB
  • di alto livello, molto astrazione cordiale ma non forzata. Ottieni comunque pieno accesso al database se ne hai bisogno. Fornisce un NSDictionary del risultato con ogni elemento automaticamente tipizzato alla variante mutabile del tipo di dati corretto (ad esempio, le colonne di testo vengono restituite come NSMutableString). Ho finito per costruire una classe wrapper molto semplice attorno ad essa per astrarla ancora di più, quindi ho una classe helper con funzioni statiche come selectAllFrom:(NSString *)table where:(NSDictionary *)conditions, che restituisce uno NSArray di oggetti NSDictionary.È fantastico essere in grado di fare cose come NSArray *usersNamedJoe = [DBHelper selectAllFrom:@"user" where:@{@"name": @"Joe"}];.

In sostanza, mentre il Core Data può essere utile per semplici iOS-solo le applicazioni, e chiunque sia interessato ad utilizzare banche dati cross-platform dovrebbe stare lontano, molto lontano da esso - Apple non ha alcun interesse a fare così facile , e mostra.

---

TL; DR:

• Non utilizzare sqlite3 grezzo a meno che non si sta facendo qualcosa di estremamente banale.
• I dati di base vanno bene per i soli dati semplici di iOS, se ci si sente a proprio agio nel bloccarli.
• Se si desidera il pieno controllo del database e non si sta facendo qualcosa di banale, o si sta costruendo l'app per più piattaforme, FMDB è sicuramente la strada da percorrere.

Answer 6

Come un nuovo tipo SQL, ho intenzione di gettare nel mio .02:

In Core Data, avete un po 'di codice "boilerplate" che è necessario mettere in prima di poter effettivamente usa il tuo database. La tua app richiede almeno uno di questi: 1) Un coordinatore di negozio persistente 2) Un contesto dell'oggetto gestito 3) Un oggetto gestito. Questo è correlato a un'entità, che è correlata a una tabella se si utilizza un database SQLite.

Per sfruttare appieno il framework, è necessario comprendere il ruolo che questi oggetti svolgono nella gestione dei dati.

D'altra parte, abbiamo SQLite, che - a mio parere - è molto più facile da capire. Per iniziare, è necessario: 1) Un database 2) Una tabella o più (a seconda dei dati) 3) Conoscenza di SQL: un linguaggio flessibile con una sintassi semplicistica (le query SELECT fanno più di quanto si potrebbe originariamente pensa di farlo) 4) Un oggetto attraverso il quale la tua app comunica con SQLite.