Dữ liệu cốt lõi VS Sqlite hoặc FMDB ....?

Question

Bây giờ điều này có thể trông giống như một chủ đề trùng lặp, nhưng câu hỏi của tôi là tôi đã đọc rất nhiều câu hỏi như .. Core Data vs SQLite 3 và những người khác nhưng đây là 2-3 năm tuổi. Tôi cũng đã đọc rằng FMDB đã được phát triển như là dữ liệu cốt lõi không được hỗ trợ trên iOS, Vì vậy, nó không nên được sử dụng nữa. Và mặt khác tôi đã đọc rằng người ta không nên sử dụng dữ liệu cốt lõi làm cơ sở dữ liệu.

Vì vậy, tôi rất bối rối, liệu tôi có nên sử dụng dữ liệu cốt lõi để lưu trữ đối tượng hay không. Ý tôi là trên cơ sở nào tôi nên quyết định nên sử dụng cái nào? Có bất kỳ hướng dẫn nào được cung cấp bởi táo hay người khác .. hay là nó sẽ đến với tôi theo thời gian.?

Answer 1

Ankit,

Dưới đây là tl; dr skinny: sử dụng Core Data.

Đây là dạng dài:

Trong khi bạn có thể sử dụng nhiều tiêu chí để lựa chọn giữa Core Data, một ORM (FMDB) hoặc cuộc gọi sqlite trực tiếp, chi phí thực sự của sự lựa chọn này xuất phát từ thời gian của bạn để sử dụng nó, Apple hỗ trợ và tận dụng từ các dự án khác. (RESTKit, bản đồ dịch vụ REST trên dữ liệu cốt lõi, là phổ biến những ngày này.)

Do đó, một tỷ lệ lớn thời gian, nói 90 +% (một stat được tạo), câu trả lời trên iOS sẽ được sử dụng Dữ liệu cốt lõi. Tại sao? Một khi bạn nhận được hang của nó và xây dựng ra một vài phương pháp trợ giúp nhỏ, Core Data giúp bạn trong một thế giới tính toán nhất quán - đồ thị đối tượng-C. Dữ liệu cốt lõi sẽ dạy bạn những điều về cách sử dụng một ngôn ngữ động sẽ giúp mọi khía cạnh khác của lập trình iOS của bạn. Do đó, bạn có năng suất cao hơn. Đừng chống lại khuôn khổ.

Nếu bạn đang sử dụng một lược đồ cơ sở dữ liệu SQLite lớn, phức tạp & từ một ứng dụng khác, thì có thể có hiệu quả về chi phí khi sử dụng FMDB hoặc SQLite. Nhưng tôi nghi ngờ nó. Thời gian của bạn viết một ứng dụng dòng lệnh dựa trên Mac đơn giản để di chuyển DB sang một DB dữ liệu cốt lõi là một nhiệm vụ hữu hạn và đơn giản. Bạn gần như chắc chắn phải viết lại hầu hết logic nghiệp vụ trong Objective-C. (Có, C++ và Objective-C++ là cả hai công nghệ tốt. Có logic nghiệp vụ cơ sở dữ liệu của bạn thực sự được điều chỉnh để hoạt động trên một thiết bị hạn chế bộ nhớ? Tôi không nghĩ vậy.)

Dữ liệu cốt lõi nhận được hiệu suất. Nó thực sự khá nhanh. Bạn chỉ cần sử dụng nó khác với bạn sử dụng một DB. Đặc biệt, bạn hầu như luôn luôn tìm nạp dữ liệu từ cửa hàng và sau đó tinh chỉnh nó bằng cách sử dụng các vị từ trực tiếp trên các bộ và mảng khác nhau.Trên các thiết bị iOS, nơi flash chậm đáng ngạc nhiên, chiến lược tìm nạp quá mức này đặc biệt hiệu quả. Bạn thực sự có rất nhiều RAM trên các thiết bị này, sử dụng nó để đạt được hiệu suất. Nhưng thực sự, mã được chuyển từ môi trường máy tính để bàn hoặc máy chủ có rất nhiều giả định tiềm ẩn về tốc độ của đĩa, số lượng bộ nhớ và thực tế của một máy ảo có cửa hàng sao lưu, nó sẽ không hoạt động tốt trên thiết bị có bộ nhớ hạn chế pin, bộ nhớ hạn chế với kiểu bộ nhớ sôi nổi. [Nó cũng sẽ không hoạt động tốt trên các thiết bị Android.]) Bạn cũng sẽ làm chuẩn hóa dữ liệu của mình để đơn giản hóa hiển thị nó trong các tiện ích giao diện người dùng iOS và Mac OS X khác nhau. Có một vài ứng dụng mà Dữ liệu cốt lõi sẽ chậm hơn so với một DB SQLite tương đương. Những chi tiết đó đã được chi tiết ở nơi khác. Một trong những yêu cầu chính là các nhiệm vụ trong đó các ID được xác định bởi các cơ sở dữ liệu ngược dòng truy cập hiệu năng của Dữ liệu cốt lõi là đúng. Nhưng nó có thể được giảm nhẹ bằng cách lập chỉ mục và tìm nạp quá mức.

Điều cần nhớ về thiết bị di động là kích thước cơ sở dữ liệu, vì đây là những thiết bị di động trên lá của internet, thường có kích thước khiêm tốn. Do đó, hiệu suất là dễ dàng hơn để đạt được. Nhiều bài học từ thế giới máy chủ có thể không áp dụng cho thế giới di động chạy bằng pin này.

Nói cách khác, bạn phải sử dụng Objective-C trên iOS/Mac OS X, bạn sẽ đạt được một số lợi ích về năng suất quan trọng khi sử dụng Dữ liệu cốt lõi.

Andrew

Answer 2

Dữ liệu cốt lõi chỉ là một sự trừu tượng hóa đối tượng của cơ sở dữ liệu SQLite3. Điều đó có nghĩa là bạn sẽ có các đối tượng liên tục dễ quản lý cho các hoạt động cơ sở dữ liệu chuẩn. Bạn cũng có thể làm việc trong một chế độ giao dịch và thiết kế cấu trúc cơ sở dữ liệu cốt lõi của bạn trong XCode bằng cách tạo ra các mô hình.

Nếu bạn không muốn tạo cơ sở dữ liệu SQLite3 theo cách thủ công hoặc phương pháp lâu dài, hãy sử dụng Dữ liệu lõi.

Answer 3

Tôi sử dụng FMDB cho tất cả các dự án có sử dụng nhiều "INSERT s" và FMDB không lỗi thời. Cam kết cuối cùng trên Github là vào tháng 11 năm ngoái. Nếu bạn đi với SQL tôi khuyên bạn nên sử dụng FMDB.

Dữ liệu cốt lõi phù hợp với 95% của tất cả các dự án, nhưng nếu nói đến tối ưu hóa để chạy đến tường. Nếu bạn muốn những lợi ích của Core Data (OOP, ...) thì hãy sử dụng nó. Nếu bạn có rất nhiều chèn một xóa với "WHERE" user Sqlite (FMDB)

POST này giải thích sự ra và trang web hàng đầu cho Core ngày vs Sqlite (FMDB)

Answer 4

CoreData là không chỉ là một khái niệm trừu tượng của một cơ sở dữ liệu SQL. CoreData cũng là đối tượng quản lý đồ thị. CoreData có thể làm những điều mà FMDB không thể làm được.

Như mọi khi: Nó thực sự phụ thuộc vào trường hợp sử dụng của bạn. Nhưng trong 99% các trường hợp, CoreData là sự lựa chọn đúng đắn.

Nếu hiệu suất rất quan trọng, bạn vẫn phải hiểu cơ sở dữ liệu hoạt động như thế nào. Nhưng CoreData có thể cung cấp hiệu suất đó nếu bạn sử dụng nó đúng cách. Nhưng phải mất một thời gian để học. Có rất nhiều điều không quan trọng để làm trong CoreData sẽ rất phức tạp trong FMDB.

Answer 5

Gần đây tôi đã bắt tay vào hành trình này và cuối cùng đã cố gắng hết cả ba. Đây là những gì tôi đã học:

• liệu SQLite3
  • Low-level, truy cập vào cơ sở dữ liệu. Không trừu tượng. Rất tiết kiệm - phải mất rất nhiều mã để làm những việc rất đơn giản.
• Core Data
  • Rất cao cấp, được xây dựng trên khái niệm trừu tượng, PHẢI sử dụng cơ sở dữ liệu được tạo ra của Apple. Hữu ích cho việc đồng bộ hóa iCloud và quản lý dữ liệu đơn giản chỉ dành cho iOS. Khó khăn và nguy hiểm để truy cập trực tiếp vào cơ sở dữ liệu, và không nên được sử dụng cho các cơ sở dữ liệu đa nền tảng. Vẫn phải mất một số tiền hợp lý của mã để làm những việc đơn giản.
• FMDB
  • cao cấp, rất trừu tượng thân thiện nhưng không bắt buộc. Vẫn có quyền truy cập đầy đủ vào cơ sở dữ liệu nếu bạn cần. Cung cấp NSDictionary kết quả với mỗi mục được tự động nhập vào biến thể có thể thay đổi của kiểu dữ liệu thích hợp (ví dụ: các cột văn bản được trả về là NSMutableString). Tôi đã kết thúc việc xây dựng một lớp bao bọc rất đơn giản xung quanh nó để trừu tượng hóa nó hơn nữa, vì vậy tôi có một lớp trợ giúp với các hàm tĩnh như selectAllFrom:(NSString *)table where:(NSDictionary *)conditions, trả về một đối tượng NSArray của NSDictionary.Thật tuyệt vời khi có thể thực hiện những việc như NSArray *usersNamedJoe = [DBHelper selectAllFrom:@"user" where:@{@"name": @"Joe"}];.

Về cơ bản, trong khi Core Data có thể hữu ích dành cho iOS chỉ đơn giản ứng dụng, bất cứ ai quan tâm đến việc sử dụng cơ sở dữ liệu đa nền tảng nên ở xa, rất xa từ nó - Apple không có sự quan tâm trong việc đưa ra dễ dàng , và nó cho thấy.

---

TL; DR:

• Không sử dụng sqlite3 liệu, trừ khi bạn đang làm một cái gì đó cực kỳ tầm thường.
• Dữ liệu cốt lõi là tốt cho dữ liệu đơn giản chỉ dành cho iOS, nếu bạn cảm thấy thoải mái khi bị khóa vào đó.
• Nếu bạn muốn toàn quyền kiểm soát cơ sở dữ liệu và bạn không làm điều gì đó tầm thường, hoặc bạn đang xây dựng ứng dụng của mình cho nhiều nền tảng, FMDB chắc chắn là cách để đi.

Answer 6

Là một chàng trai SQL mới, tôi sẽ ném vào tôi .02:

Trong Core Data, bạn có một chút "soạn sẵn" mã mà bạn cần để đưa vào trước khi bạn có thể thực sự sử dụng cơ sở dữ liệu của bạn. Ứng dụng của bạn cần ít nhất một trong các yêu cầu sau: 1) Điều phối viên cửa hàng liên tục 2) Ngữ cảnh đối tượng được quản lý 3) Đối tượng được quản lý. Điều này tương quan với một thực thể, tương quan với một bảng nếu bạn sử dụng một cơ sở dữ liệu SQLite.

Để tận dụng toàn bộ khung công tác, bạn cần hiểu vai trò của các đối tượng này trong việc quản lý dữ liệu của mình.

Mặt khác, chúng tôi có SQLite, theo ý kiến ​​của tôi - dễ hiểu hơn nhiều. Để bắt đầu, bạn sẽ cần: 1) Cơ sở dữ liệu 2) Bảng hoặc nhiều hơn (tùy thuộc vào dữ liệu của bạn) 3) Kiến thức về SQL - một ngôn ngữ linh hoạt với cú pháp đơn giản (truy vấn SELECT làm nhiều hơn những gì bạn có thể ban đầu nghĩ rằng họ làm) 4) Một đối tượng mà qua đó ứng dụng của bạn giao tiếp với SQLite.