Việc sử dụng một máy chủ cơ sở dữ liệu có ý nghĩa nếu ứng dụng chỉ thực hiện mọi thứ cục bộ?

Tôi đã thấy một số ứng dụng về cơ bản là phần mềm ứng dụng chạy cục bộ vào hệ thống (vì vậy chúng không giao tiếp nhiều qua mạng). Các ứng dụng này dường như phụ thuộc vào máy chủ cơ sở dữ liệu để lưu trữ dữ liệu của họ.

Một ví dụ về một ứng dụng là Amarok (một trình phát nhạc phổ biến trên Linux). Tôi không biết liệu họ có còn làm điều này không, nhưng tôi nhớ đã có lúc cài đặt Amarok có nghĩa là bạn phải cài đặt máy chủ MySQL và chạy nó ở chế độ nền mọi lúc.

Lợi thế của việc sử dụng máy chủ để lưu trữ cục bộ so với sử dụng giải pháp SQL nhúng nhỏ hơn như sqlite là gì? Tôi đang nói về phần mềm ứng dụng nói chung, không nhất thiết phải là amarok (đó chỉ là một ví dụ). Có bất kỳ tình huống trong đó sử dụng một máy chủ cơ sở dữ liệu có ý nghĩa so với một cơ sở dữ liệu nhúng?

SQLite cung cấp một danh sách khá tốt về thời điểm sử dụng hay không so với các lựa chọn thay thế:

https://www.sqlite.org/weaverouse.html

Dòng tóm tắt này nắm bắt trường hợp sử dụng SQLite cực kỳ tốt theo kinh nghiệm của tôi:

SQLite không cạnh tranh với cơ sở dữ liệu máy khách / máy chủ. SQLite cạnh tranh với fopen ().

Bài viết mở rộng ở độ dài về điểm này. Nó cũng có một phần có tiêu đề "Các tình huống trong đó RDBMS của máy khách / máy chủ có thể hoạt động tốt hơn". Tóm lại, chúng là:

• Ứng dụng Máy khách / Máy chủ : nhiều người dùng qua mạng.
• Trang web có khối lượng lớn : viết chuyên sâu hoặc đọc đủ chuyên sâu để yêu cầu shending.
• Bộ dữ liệu rất lớn : lớn hơn có thể được lưu trữ hợp lý trên một đĩa.
• Đồng thời cao : đặc biệt là viết đồng thời.

Ngay cả đối với một hệ thống duy nhất có một người dùng, máy chủ cơ sở dữ liệu "thực" có ý nghĩa:

1. Nó sử dụng một ngôn ngữ quen thuộc ( SQL ). SQLite sử dụng SQL, nhưng một số cơ sở dữ liệu nhúng (ví dụ: cơ sở dữ liệu đối tượng , NoQuery ) không sử dụng SQL. Những người có xu hướng có một đường cong học tập cao hơn bởi vì chúng ít phổ biến hơn.
2. Nó cung cấp tính toàn vẹn tham chiếu, các ràng buộc, kích hoạt, vv mà các sản phẩm như SQLite có thể không cung cấp hoặc ít nhất là không cung cấp đầy đủ.
3. Bằng cách nhắm mục tiêu cơ sở dữ liệu mạng tuân thủ ACID nhiều người dùng thực sự , ứng dụng có tùy chọn làm việc trong một kịch bản máy trạm / người dùng đơn hoặc như một ứng dụng được lưu trữ nhiều người dùng, sử dụng cùng một cơ sở mã .
4. Người dùng có khả năng kiểm tra dữ liệu ngoại tuyến bằng các công cụ tiêu chuẩn (ví dụ: SQL Developer, MySQL Workbench, SQL Server Management Studio), tải hoặc sao lưu dữ liệu bằng các công cụ đó, v.v. Mặc dù có thể làm như vậy với nhiều cơ sở dữ liệu nhúng khác nhau các loại, mọi người có thể quen thuộc hơn với các công cụ từ thế giới cơ sở dữ liệu C / S.

Hạn chế chính là cần cài đặt và bảo trì phần mềm máy chủ cơ sở dữ liệu, điều này hơi phức tạp đối với người dùng không có kỹ thuật (và thậm chí nhiều người dùng kỹ thuật). Các hệ điều hành như Linux giúp việc này trở nên dễ dàng hơn: Tôi có PostgreSQL và MySQL chạy trên hệ thống Linux của tôi. Tôi đã cài đặt các ứng dụng được nối với chúng mà không có sự tương tác nào từ phía tôi.

Tôi nghĩ rằng nó phải làm với quán tính.

Amarok dựa trên XMMS từ năm 1997. Để có khả năng cơ sở dữ liệu tốt, bạn phải sử dụng máy chủ, vì nó mạnh hơn rất nhiều so với các giải pháp dựa trên tệp, mà không có nghĩa là có khả năng cơ sở dữ liệu tốt.

Sự phổ biến sắp tới và ngày càng phổ biến của các cơ sở dữ liệu nhúng cục bộ tốt như SQLlite là một cái gì đó khá gần đây.

Tính năng phân biệt đối xử quan trọng nhất là đồng thời .

Nếu bạn chỉ có một ứng dụng chạy trong một phiên bản cho người dùng, giải pháp nhúng (cho dù là sqlite hoặc một số lưu trữ đối tượng) thường là OK.

Tuy nhiên, nếu bạn có nhiều trường hợp cần thao tác cơ sở dữ liệu đồng thời, bạn cần phải có một máy chủ để đồng bộ hóa nó. SQLite chỉ cho phép viết một lần, trong toàn bộ cơ sở dữ liệu và hầu hết các giải pháp nhúng khác cũng vậy. Và nếu bạn thậm chí có nhiều ứng dụng, bạn có thể cần đặc tả ràng buộc chi tiết hơn mà các giải pháp nhúng thường không cho phép.

Nhiều câu trả lời khác nói về đồng thời là một lợi thế, nhưng cũng vì db đang chạy như một máy chủ, cơ sở dữ liệu có thể chạy các tác vụ mà không cần ứng dụng chạy. Đây có thể là bảo trì, sao lưu, đồng bộ hóa với máy chủ khác hoặc bất kỳ tác vụ theo lịch trình.

Nếu bạn cảm thấy ứng dụng của mình có thể biến thành ứng dụng khách / máy chủ, bạn có thể muốn bắt đầu bằng cách sử dụng RDBMS từ đầu thay vì chuyển nó qua sau.

Tôi không biết liệu ví dụ đưa ra có tận dụng điều này hay không.

Trừ khi bạn đang chạy một hệ thống nhúng với bộ nhớ và cpu thấp, tôi không nghĩ rằng việc chạy một máy chủ trên nền sẽ gây hại cho bạn.

Chạy một máy chủ cơ sở dữ liệu cục bộ là tốt. Cơ sở dữ liệu có nghĩa là để truy cập và thao tác dữ liệu. Truy cập mạng là một lợi thế, có thể cần hoặc không cần thiết. Có một số công cụ khoa học và kỹ thuật làm điều này.

Giả sử bạn đang sử dụng dữ liệu trên ứng dụng cục bộ. Tại sao bạn không nên sử dụng cơ sở dữ liệu? trái ngược với những gì?

Nó phụ thuộc vào sự trừu tượng hóa dữ liệu của bạn và không gian ứng dụng tổng thể, yêu cầu quản lý truy cập, khoản đầu tư bạn đang lên kế hoạch bảo trì dữ liệu, mức độ khẩn cấp của nguyên mẫu bắt buộc, nơi bạn đang ở trong đường cong học tập, v.v.

Nếu bạn muốn đảm bảo cơ sở dữ liệu được tích hợp chặt chẽ vào một ứng dụng không yêu cầu quyền truy cập từ các ứng dụng khác, hãy tạo các đảo cơ sở dữ liệu nhúng. Việc triển khai lưu trữ web Mozilla Firefox với SQLite có thể được đưa ra làm ví dụ.

Nếu bạn cần hiệu quả cao hơn với dữ liệu hạn chế, lựa chọn thiết kế Cơ sở dữ liệu trong bộ nhớ là thích hợp hơn.

Mặt khác, nếu bạn có nhiều ứng dụng chạy nhiều truy vấn trên cùng một dữ liệu và nó yêu cầu cấu trúc lưu trữ dữ liệu tốt hơn để tối ưu hóa hiệu suất, thì cần phải có DBMS tập trung. Tôi hoàn toàn thích nó cho nghiên cứu khoa học, khi nó đòi hỏi lượng dữ liệu khổng lồ và thời gian phản hồi truy vấn sẽ tác động mạnh mẽ đến trải nghiệm người dùng nói chung.

Đối với trường hợp Amarok, tôi đoán đó là một lựa chọn DBMS nguồn mở tại thời điểm đó, trước khi họ chọn đường dẫn của cơ sở dữ liệu nhúng.

Nếu có một định nghĩa hệ thống cụ thể trong tay của bạn, nó sẽ dễ dàng hơn để cân và nhược điểm.

V / r, Umut