SQLite ve Paylaşılan Tercihlerin Artıları ve Eksileri [kapalı]


156

SQLite veritabanı ve Paylaşılan Tercihler arasında bilgi depolamanın iyi mekanizması nedir?

Paylaşılan tercihleri ​​neden kullanmalıyım? Neden sqlite kullanılır? Aralarındaki farkı bulmaya çalıştım ve bu da veri depolama için daha iyi bir mekanizma, ancak Google'da uygun cevabı bulamıyorum. Lütfen bana örnek ve açıklamalar konusunda yardımcı olun.


Hemen hemen saklamak istediğiniz veri türüne bağlıdır. SharedPreferences, verilere daha hızlı ve daha kolay erişim sağlar, az miktarda veri tutarken kullanımı daha rahattır.
Egor

2
Paylaşılan Tercihler'de basit dizeler ve ilkel öğeler dışında hiçbir şey saklamayın - ve her biri için ayrı bir dosya kullanırsanız - Paylaşılan Tercihler iş parçacığı açısından güvenli değildir ve yalnızca ana iş parçacığında kullanılsa bile, daha fazla saklamanız gerekir bir dosyada 1'den fazla anahtar / değer çifti.
RunLoop

SharedPreferences ilk kullanımdan sonra bellekte önbelleğe alınır, bu nedenle sonraki Read kullanımlarında oldukça hızlı olmalıdır.
Stan

Yanıtlar:


169

Bu gerçekten depolamak istediğiniz verilere bağlıdır.

SQLite

Bu tür veriler için veritabanları tasarlandığından, büyük miktarlarda aynı yapılandırılmış veri SQLite veritabanında depolanmalıdır. Veri veritabanı tarafından yapılandırılıp yönetildiği için, SQL gibi bir sorgu dili kullanarak belirli ölçütlerle eşleşen verilerin bir alt kümesini almak için sorgulanabilir. Bu, verilerde arama yapmayı mümkün kılar. Tabii ki büyük veri kümelerini yönetmek ve aramak performansı etkiler, böylece bir veritabanından veri okumak SharedPreferences'den veri okumaktan daha yavaş olabilir.

Paylaşılan Tercihler

SharedPreferences, belirli bir anahtarın altına veri kaydedebileceğiniz bir anahtar / değer deposudur. Mağazadan veri okumak için verinin anahtarını bilmeniz gerekir. Bu, verileri okumayı çok kolaylaştırır. Ancak, her bir veri için anahtar tanımlamanız gerektiğinden, küçük bir miktarda veriyi saklamak ve büyük yapılandırılmış verileri saklamak kadar kolay olduğu kadar, belirli bir kavramınız dışında verilerde gerçekten arama yapamazsınız. tuşları adlandırma.


24
Bir örnek vermek gerekirse, SharedPreferences, depolanması gereken bir avuç değişkenin bulunduğu kullanıcı tercihlerini saklamak için kullanışlıdır. Öte yandan SQLite, araştırılması gereken bir müzik kütüphanesinde şarkı başlıkları gibi çok sayıda öğenin bulunduğu verileri depolamak için daha iyi olur.
CL22

5
SharedPreferences'ı kullanmak için anahtar adlarını bilmenize gerek yoktur. Bkz. GetAll ().
ZaBlanc

5
FYI, bir ÜÇÜNCÜ seçeneği var: bir dosyaya XML okuma / yazma. (Bkz. Android.util.xml sınıfları). Bir kerede okunabilen / yazılabilen orta derecede karmaşık veriler için uygundur. Örneğin, kullanıcının sık sık değişmediği bir değerler ızgarası. Özellikle daha sonra başka bir yere göndermek isteyebileceğiniz verilerse, ayrıştırılabilir bir biçimde gerekecektir.
19:33

1
json'u paylaşılan pref'ye json dizesi olarak kaydetmeniz tavsiye edilir mi?
Kaveesh Kanwal

2
@JCarlos Bazı çapraz süreçler yapmadığınız sürece, SharedPreferences'ı kullanmaya devam edersiniz.
Mygod

97

Bu sorunun kabul edilmiş bir cevabı var, ancak bence konu hakkında daha fazla şey var - hız ile ilgili.

Bir uygulamanın SharedPreferences ve Sqlite DB'si, yalnızca uygulamanın dosya dizinindeki uygulamanın dizinlerinde depolanan dosyalardır. Veri miktarı çok büyük değilse, Sqlite seçeneği daha basit ve daha karmaşık bir dosya içerecektir.

Bu nedenle, verilerin niteliği seçiminizi (kabul edilen cevapta açıklandığı gibi) ve hız önemli değilse, o zaman muhtemelen SharedPreferences'ı kullanmak daha iyidir.

Ve bazı verileri okumak genellikle ana aktiviteyi göstermenin kritik yolundadır, bu yüzden hızın genellikle çok önemli olduğunu düşünüyorum.

Hız ve verimlilikle ilgili son bir düşünce - bazı yapılandırılmış veriler için bir Sqlite veritabanı kullanmanız gerekiyorsa, ikinci bir dosyayı açmamanız için kullanıcı tercihlerini veritabanında depolamak da muhtemelen daha etkilidir. Bu oldukça küçük bir düşüncedir - muhtemelen sadece ana etkinliği görüntülemeden önce hem yapılandırılmış verilere hem de tercihlere erişmeniz gerekiyorsa dikkate alınmalıdır.


6
Kod okunabilirliği ne olacak? Ben bir db tablo yerine SharedPrefs birden çok kayıt depolarken, kod kıvrık hale düşünüyorum. Sql sözdizimini okumak SharedPrefs girişleri üzerinde döngü daha kolay ...
IgorGanapolsky

8
Igor, katılmıyorum. SharedPreferences gerçekten 1 boyutlu, bir tercih kullanmak çok basit. Örneğin, bir stok kontrol uygulaması oluşturuyorum, hisse senedi sembollerini tercihlerde saklıyorum. Her zaman hepsini listelediğim için onları tek tek almam gerekmiyor ve yaptığım, depoladığım veya yakaladığım tek şey bu. Bir DB kullanmaktan çok basit, çok daha basit.
AutoM8R

1
Kaydedilecek verilerin yapısı hiyerarşik bir veritabanı kullanılmasını gerektirmezken, kodun okunabilirliğinin zorlaştığı bir durumu düşünemiyorum. Okunabilirlik sorunları olsa bile, gerekli işlevlere sahip bir sarıcı sınıfı kullanılarak çözülebilir.
Sarath Sadasivan Pillai

1
Paylaşılan tercihler altında jsonstring verileri biçiminde birden fazla anahtar / değer çifti saklayabilir miyiz? Json değerlerimi kısaltabilecek bir karakter sınırı var mı?
Nova

2
SharedPreferences belleğe yalnızca bir kez yüklenir (uygulama işlemi yaşam döngüsü başına) ve orada tutulur; bundan sonra her zaman süper hızlı. Bu nedenle, SharedPref verilerini SQLite'ye koyarak hiçbir pratik performans kazancı yoktur (sadece ekstra SharedPref dosya erişiminden kaçınmak için). Ve bu arada SQLite öğelerinizi SharedPrefs'e koymamalısınız; Dediğim gibi, her zaman bellekte size sorunlara neden olabilir (bellek dışı olanlar).
Zsolt Safrany

20

Benim almam, hız veya boyut değil, verilerinize yapmak istediğiniz işlem türleriyle ilgilidir.

Eğer do planlıyorsanız katılmak , sıralama , ve diğer DB işlemleri Verilerinizden sonra gitmek SQLite . Bir örnek, verileri tarihe göre sıralamaktır.

Basit değerleri (int, boolean, String gibi) eşlemek istiyorsanız Tercihler'i kullanın . DB işlemleri burada çalışmaz ve tüm anahtarlara sahip olmanız gerektiğini söylemeye gerek yok. Örnek olarak kullanıcı şifresi veya uygulama yapılandırması verilebilir.

Tercihleri ​​kucaklamak için büyük cazibe, düzleştirilmiş bir POJO'yu (serileştirilmiş bir JSON nesnesi) String olarak saklamak istediğinizde kullanmaktır. Böyle bir ihtiyaca sahip olmak aslında Sqlite kullanmak için işarettir. Neden ? Çünkü karmaşık veriler sonunda karmaşık seçimlere ihtiyaç duyacaktır. Basit bir "SELECT ... WHERE id = 1" ile işlenebilecek belirli bir girişi aldığınızı düşünün. Tercihler yolunda, bu, serileştirmeden sonuçların yinelenmesine kadar uzun bir süreç olacaktır.


Ayrıca, SharedPreferences işlemleri desteklemediğinden, işlemlere ihtiyacınız varsa SQLite kullanın. Örneğin, kullanıcı bir "oturumu kapat" düğmesine basarsa, SharedPreferencesaynı anda birden fazla anahtarı / değeri (örneğin hem userve passwordtuşları) silmek isteyebilirsiniz , böylece her iki tuşun da ayarlanmadığından veya her ikisinin de ayarlandığından emin olabilirsiniz.
runeks

5
  • Büyük miktarda veri depolamak için SQLite veritabanı sistemine gidin. Bu, kullanıcının verileri de aramasına olanak tanır.

  • Öte yandan, az miktarda veri depolamak için Paylaşılan Tercihler'e gidin. Bu durumda, büyük bir veritabanı sistemi gereksizdir. Bu, kullanıcının verileri kolayca kaydetmesine ve yüklemesine olanak tanır.


1
300 anahtar / değer çifti çok büyük miktarda veri mi? Tam olarak saklamam gerekiyor.
JCarlosR

1
Bu durumda, SQLite veritabanı için gitmelisiniz. Aksi takdirde, bu 300 veriyi yönetmek ve almak zor olacaktır.
Sami Al-Jabar

Ancak tüm anahtarlar biliniyorsa, Paylaşılan Tercihler'den veri almak daha kolay olmaz mı?
Arjun

-6

SQLLite unut SharedPreferences unut, bölge kullanın. Tüm yerel depolama alanlarınız için tek bir çözüm. Düz eski Java Nesnelerini RealmObjects olarak kullanabilir ve verilerinizi orada saklayabilirsiniz. Seçili sorguları JSON dosyalarına dönüştürebilirsiniz. Tüm veri tabanını ayrıştırmaya gerek yoktur. Bu bağlantıyı kontrol edin: https://realm.io/news/introducing-realm/


12
slipcovers hakkında bildiğiniz her şeyi unutun.
Andrew G
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.