Ưu và nhược điểm của SQLite và Sở thích chung [đã đóng]

155

Cơ chế tốt để lưu trữ thông tin giữa cơ sở dữ liệu SQLite và Sở thích chung là gì?

Tại sao sử dụng sở thích chung? Tại sao nên sử dụng sqlite? Tôi đã cố gắng tìm ra sự khác biệt giữa chúng và đó là cơ chế tốt hơn để lưu trữ dữ liệu, nhưng tôi không thể tìm thấy câu trả lời thích hợp trên Google. Xin hãy giúp tôi với ví dụ và giải thích.

— Rana.S
nguồn

Nó khá nhiều phụ thuộc vào loại dữ liệu bạn muốn lưu trữ. SharedPreferences cho phép truy cập dữ liệu nhanh hơn và đơn giản hơn, sử dụng thoải mái hơn khi giữ một lượng nhỏ dữ liệu.

— Egor

2

Không lưu trữ bất cứ thứ gì trong Tùy chọn được chia sẻ ngoại trừ các chuỗi đơn giản và nguyên thủy - và nếu bạn sử dụng một tệp riêng cho từng tệp - mặc dù các tài liệu Tùy chọn chia sẻ không an toàn cho chủ đề và ngay cả khi chỉ sử dụng trên luồng chính rất dễ bị hỏng, bạn nên lưu trữ nhiều hơn hơn 1 cặp giá trị chính trong một tệp.

— RunLoop

SharedPreferences được lưu trong bộ nhớ sau lần sử dụng đầu tiên, vì vậy chúng sẽ khá nhanh khi sử dụng Đọc.

— Stan

167

Nó thực sự phụ thuộc vào dữ liệu bạn muốn lưu trữ.

SQLite

Một lượng lớn dữ liệu có cấu trúc tương tự nên được lưu trữ trong cơ sở dữ liệu SQLite vì cơ sở dữ liệu được thiết kế cho loại dữ liệu này. Vì dữ liệu được cấu trúc và quản lý bởi cơ sở dữ liệu, nó có thể được truy vấn để có được một tập hợp con của dữ liệu phù hợp với các tiêu chí nhất định sử dụng ngôn ngữ truy vấn như SQL. Điều này làm cho nó có thể tìm kiếm trong dữ liệu. Tất nhiên việc quản lý và tìm kiếm các bộ dữ liệu lớn ảnh hưởng đến hiệu suất, vì vậy việc đọc dữ liệu từ cơ sở dữ liệu có thể chậm hơn so với việc đọc dữ liệu từ SharedPreferences.

SharedPreferences

SharedPreferences là một kho lưu trữ khóa / giá trị nơi bạn có thể lưu dữ liệu theo khóa nhất định. Để đọc dữ liệu từ cửa hàng, bạn phải biết khóa của dữ liệu. Điều này làm cho việc đọc dữ liệu rất dễ dàng. Nhưng việc lưu trữ một lượng dữ liệu nhỏ cũng dễ như lưu trữ và đọc dữ liệu có cấu trúc lớn khi bạn cần xác định khóa cho mỗi dữ liệu, hơn nữa bạn không thể thực sự tìm kiếm trong dữ liệu trừ khi bạn có một khái niệm nhất định cho đặt tên cho các phím.

— Lũ
nguồn

24

Để đưa ra một ví dụ, SharedPreferences rất hữu ích để lưu trữ các tùy chọn của người dùng, trong đó chỉ có một số biến cần lưu trữ. Mặt khác, SQLite sẽ tốt hơn cho việc lưu trữ dữ liệu khi có một bộ lớn các mục, chẳng hạn như tên bài hát trong thư viện nhạc cần tìm kiếm.

— CL22

5

Bạn không cần biết tên chính để sử dụng SharedPreferences. Xem get ALL ().

— ZaBlanc

5

FYI, có một tùy chọn THIRD: đọc / ghi XML vào một tệp. (Xem các lớp android.util.xml). Thích hợp cho dữ liệu phức tạp vừa phải có thể đọc / ghi tất cả cùng một lúc. Ví dụ: lưới các giá trị mà người dùng không thay đổi thường xuyên. Đặc biệt nếu đó là dữ liệu mà sau này bạn có thể muốn gửi ở nơi khác, do đó sẽ cần ở định dạng có thể phân tích cú pháp.

— ToolmakerSteve

1

Có nên lưu chuỗi json dưới dạng chuỗi json trong pref pref không?

— Kaveesh Kanwal

2

@JCarlos Miễn là bạn không thực hiện một số công việc xử lý chéo, bạn sẽ ổn khi sử dụng SharedPreferences.

— Mygod

96

Câu hỏi này có một câu trả lời được chấp nhận, nhưng tôi nghĩ có nhiều điều để nói về chủ đề này - liên quan đến tốc độ.

SharedPreferences và Sqlite DB của ứng dụng đều chỉ là các tệp, được lưu trữ trong các thư mục của ứng dụng trên hệ thống tệp của thiết bị. Nếu lượng dữ liệu không quá lớn, tùy chọn Sqlite sẽ liên quan đến một tệp lớn hơn và phức tạp hơn với nhiều chi phí xử lý hơn để truy cập đơn giản.

Vì vậy, nếu bản chất của dữ liệu không quyết định lựa chọn của bạn (như được giải thích trong câu trả lời được chấp nhận) và vấn đề tốc độ, thì có lẽ tốt hơn là bạn nên sử dụng SharedPreferences.

Và việc đọc một số dữ liệu thường nằm trên đường dẫn quan trọng để hiển thị hoạt động chính vì vậy tôi nghĩ tốc độ thường rất quan trọng.

Một suy nghĩ cuối cùng liên quan đến tốc độ và hiệu quả - nếu bạn cần sử dụng cơ sở dữ liệu Sqlite cho một số dữ liệu có cấu trúc thì có lẽ sẽ hiệu quả hơn khi lưu trữ tùy chọn người dùng trong cơ sở dữ liệu để bạn không mở tệp thứ hai. Đây là một xem xét khá nhỏ - có lẽ chỉ đáng xem xét nếu bạn cần truy cập cả dữ liệu có cấu trúc và tùy chọn trước khi bạn có thể hiển thị hoạt động chính.

— Tom
nguồn

6

Điều gì về khả năng đọc mã? Tôi nghĩ rằng khi lưu trữ nhiều bản ghi trong SharedPrefs thay vì bảng db, mã sẽ trở nên phức tạp. Cú pháp Sql dễ đọc hơn so với việc lặp qua các mục của

— SharedPrefs

8

Igor, tôi không đồng ý. SharedPreferences thực sự là một chiều, rất dễ sử dụng tùy chọn. Chẳng hạn, tôi đang xây dựng một ứng dụng kiểm tra chứng khoán, tôi chỉ đơn giản là lưu trữ các biểu tượng chứng khoán trong các tùy chọn. Tôi không cần phải lấy chúng một cách riêng lẻ, vì tôi luôn liệt kê tất cả chúng, và đây là tất cả những gì tôi làm, lưu trữ hoặc lấy. Thật đơn giản, đơn giản hơn nhiều so với việc sử dụng DB.

— AutoM8R

1

Tôi không thể nghĩ đến một tình huống mà khả năng đọc mã trở nên khó khăn trong khi cấu trúc dữ liệu được lưu không yêu cầu sử dụng cơ sở dữ liệu phân cấp. Ngay cả khi có bất kỳ vấn đề dễ đọc nào, nó vẫn có thể được giải quyết bằng cách sử dụng lớp bao bọc với các chức năng được yêu cầu.

— Sarath Sadasivan Pillai

1

Chúng tôi có thể lưu trữ nhiều giá trị khóa dưới dạng dữ liệu json chuỗi theo tùy chọn chia sẻ không? Có giới hạn ký tự nào có thể cắt các giá trị json của tôi không?

— Nova

2

SharedPreferences chỉ được tải vào bộ nhớ một lần (mỗi vòng đời của quá trình ứng dụng) và được giữ ở đó; sau đó nó luôn siêu nhanh. Vì vậy, thực sự không có bất kỳ chiến thắng hiệu suất thực tế nào bằng cách đưa dữ liệu SharedPref vào SQLite (chỉ vì mục đích tránh truy cập thêm tệp SharedPref). Và bằng cách này, bạn không nên đặt công cụ SQLite của mình vào SharedPrefs; như tôi đã nói, nó luôn ở trong bộ nhớ có thể gây ra sự cố cho bạn (những người không có bộ nhớ).

— Zsolt Safrany

20

Tôi nghĩ là, nó không phải là về tốc độ hoặc kích thước mà là các loại hoạt động bạn muốn làm với dữ liệu của bạn.

Nếu bạn có kế hoạch để làm tham gia , loại , và các hoạt động DB khác trên dữ liệu của bạn sau đó đi cho Sqlite . Một ví dụ là sắp xếp dữ liệu theo ngày.

Nếu bạn muốn ánh xạ các giá trị đơn giản (như int, boolean, String) thì hãy sử dụng Preferences . Các hoạt động DB sẽ không hoạt động ở đây và không cần phải nói rằng bạn cần phải có tất cả các khóa. Một ví dụ là mật khẩu người dùng hoặc cấu hình ứng dụng.

Sự cám dỗ lớn để nắm lấy Sở thích là khi bạn muốn sử dụng nó để lưu trữ POJO (một đối tượng JSON được tuần tự hóa) dưới dạng Chuỗi. Có nhu cầu như vậy thực sự là dấu hiệu để sử dụng Sqlite. Tại sao ? Bởi vì dữ liệu phức tạp cuối cùng sẽ cần các thao tác phức tạp. Hãy tưởng tượng lấy một mục cụ thể có thể được xử lý bằng một "CHỌN ... WHERE id = 1" đơn giản. Trong đường dẫn Tùy chọn, đây sẽ là một quá trình dài từ khử lưu lượng đến lặp lại kết quả.

— inmyth
nguồn

Ngoài ra, SharedPreferences không hỗ trợ giao dịch, vì vậy nếu bạn cần giao dịch thì hãy sử dụng SQLite. Ví dụ: nếu người dùng nhấn nút "đăng xuất", bạn có thể muốn xóa nhiều SharedPreferenceskhóa / giá trị cùng một lúc (ví dụ: cả phím uservà passwordkhóa), để bạn chắc chắn rằng cả hai khóa đều không được đặt hoặc cả hai khóa đều được đặt.

— runeks

5

Để lưu trữ lượng dữ liệu khổng lồ, hãy truy cập hệ thống cơ sở dữ liệu SQLite. Điều này sẽ cho phép người dùng tìm kiếm dữ liệu là tốt.
Mặt khác, để lưu trữ một lượng nhỏ dữ liệu, hãy truy cập Tùy chọn chia sẻ. Trong trường hợp này, một hệ thống cơ sở dữ liệu khổng lồ là không cần thiết. Điều này sẽ cho phép người dùng chỉ cần lưu dữ liệu và tải chúng.

— Sami Al-Jabar
nguồn

1

300 cặp khóa-giá trị là một lượng dữ liệu khổng lồ? Tôi cần lưu trữ chính xác.

— JCarlosR

1

Trong trường hợp đó, bạn nên truy cập cơ sở dữ liệu SQLite. Nếu không, sẽ khó quản lý và truy xuất 300 dữ liệu đó.

— Sami Al-Jabar

Nhưng nếu tất cả các khóa được biết sẽ không dễ dàng lấy dữ liệu từ Tùy chọn chia sẻ?

— Arjun

-6

Quên SQLLite quên SharedPreferences, sử dụng Realm. Một giải pháp duy nhất cho tất cả lưu trữ cục bộ của bạn. Bạn có thể sử dụng các Đối tượng Java cũ đơn giản làm RealmObjects và lưu trữ dữ liệu của bạn ở đó. Bạn có thể chuyển đổi các truy vấn đã chọn thành các tệp JSON. Không cần phân tích toàn bộ cơ sở dữ liệu. Kiểm tra liên kết này: https://realm.io/news/int sinhing-realm /

— rau xanh
nguồn

12

quên tất cả mọi thứ bạn biết về slcovers.

— Andrew G