Cách tốt nhất để xác định khi nào là phù hợp để sử dụng cơ sở dữ liệu?

Tôi bắt đầu sự nghiệp lập trình của mình trong phát triển web bằng PHP và MySQL. Tôi đã khá quen với việc sử dụng db để lưu trữ hầu hết các dữ liệu động cũng như một số dữ liệu cài đặt / tham số. Đôi khi sẽ có rất nhiều dữ liệu trong khi các mục khác trong các bảng sẽ ít. Đối với tôi điều này có vẻ tự nhiên và theo như tôi biết thì đây ít nhiều là một cách tiếp cận có thể chấp nhận được trong phát triển web. (Nêu tôi sai vui long chân chỉnh tôi...)

Bây giờ tôi đang đào sâu vào các ứng dụng máy tính để bàn và thiên hướng tự nhiên của tôi là một lần nữa sử dụng db để lưu trữ nhiều thông tin sẽ được tạo ra thông qua việc sử dụng ứng dụng. Tuy nhiên, theo như tôi có thể nói tôi không thấy các ứng dụng (mà tôi sử dụng) sử dụng db rất thường xuyên. [EDIT: Từ đó đã chỉ ra rằng đây là một giả định sai lầm khi nhiều ứng dụng sử dụng các dbs nhẹ được nhúng vào chính chương trình.] Lý do cho điều này là gì? Tại thời điểm nào là thích hợp để sử dụng một db? Có bất kỳ tiêu chuẩn về vấn đề này? Ngoài ra những lý do để KHÔNG sử dụng db để phát triển ứng dụng máy tính để bàn là gì?

nếu ứng dụng của bạn được định hướng theo tài liệu, hãy lưu trữ mọi thứ trong một tệp tài liệu

nếu ứng dụng của bạn xử lý dữ liệu có cấu trúc nhiều hơn, quá nhiều cho một tài liệu (như tài liệu XML), hãy sử dụng cơ sở dữ liệu

Theo truyền thống, một hệ thống cơ sở dữ liệu được coi là một dịch vụ tương đối nặng - mà bạn không nhất thiết muốn cài đặt trên mọi máy khách ngoài kia. Tôi đã thực sự gặp phải tình huống (phát triển ứng dụng GUI trên máy tính để bàn, nơi cần lưu trữ nhiều dữ liệu) trong đó một hệ thống DB thực sự sẽ là một giải pháp "lý tưởng" - nhưng vì trước đây, cơ sở dữ liệu duy nhất có sẵn tương đối nặng, chúng tôi đã đi với các tập tin dữ liệu phẳng thay thế.

Mặc dù có một số cơ sở dữ liệu nhẹ hơn hiện nay, đây vẫn là một đối số hợp lệ chống lại cơ sở dữ liệu phía khách hàng. Hãy tưởng tượng một số ứng dụng máy tính để bàn nhỏ đơn giản (chẳng hạn như một đồ chơi hoặc trò chơi đơn giản trên máy tính để bàn) phải lưu trữ vài chục cài đặt và thông số. Có vẻ như trên hết để làm cho một người cài đặt MySQL chỉ để chạy ứng dụng của bạn.

Với sự phát triển web, máy chủ tự nhiên là một back end, trong đó việc có một cơ sở dữ liệu là ngang bằng với khóa học. ví dụ. Người dùng không phải lo lắng về việc cài đặt cơ sở dữ liệu ở cuối.

Các ứng dụng máy tính để bàn duy trì trạng thái trong khi chúng đang chạy. Trong khi đó phát triển web thường không. Vì vậy, trong khi bạn có thể cần lưu trữ cài đặt người dùng trong cơ sở dữ liệu ở giữa các lần tải trang, trong ứng dụng máy tính để bàn, bạn chỉ cần giữ chúng trong bộ nhớ. Điều đó làm giảm đáng kể nhu cầu về các loại lưu trữ liên tục như vậy. Khi bạn muốn lưu trữ tùy chọn giữa các lần sử dụng, bạn có thể lưu tất cả chúng vào một tệp hoặc đặt chúng ở một nơi nào đó như sổ đăng ký Windows.

Điều đó đang được nói, hệ thống cơ sở dữ liệu được sử dụng khá nhiều trong các ứng dụng máy tính để bàn. Rất lâu trước khi có web, các ứng dụng máy tính để bàn đã được kết nối với DBMS. Chủ yếu cho các ứng dụng không dựa trên tài liệu. Mặc dù những ngày này, với sự sẵn có tốt hơn của động cơ trọng lượng nhẹ, bạn đang nắm bắt các dòng bị mờ đi một chút. Ví dụ, tôi sử dụng SQLite db làm tài liệu trong một vài ứng dụng của mình.

Một điều bạn có thể muốn xem xét là các cơ sở dữ liệu nhẹ không yêu cầu dịch vụ cơ sở dữ liệu thực tế đang chạy. ví dụ: ở mặt trước của Microsoft có SQL Server Compact , miễn phí, chỉ yêu cầu một tệp duy nhất cho cơ sở dữ liệu và một số DLL được thêm vào ứng dụng của bạn và theo quan điểm của nhà phát triển, hoạt động giống như SQL Server "thực".

Tôi tích cực có các tùy chọn tương tự trên các nền tảng khác.

Trên các ứng dụng web, điều quan trọng là lưu trữ bất kỳ trạng thái liên tục nào trên bộ lưu trữ tập trung. Vì ứng dụng web thường là nút cổ chai đầu tiên, điều quan trọng là có thể chỉ phân phối ứng dụng mà không phải đặt câu hỏi bản sao nào có dữ liệu (nguyên tắc 'Không chia sẻ gì'). Không chỉ là một cơ sở dữ liệu, mà memcachedcác hệ thống xếp hàng cũng có cùng một lý do.

Các ứng dụng máy tính để bàn không có cùng mục tiêu khả năng mở rộng. Thông thường, hầu hết dữ liệu được lưu trữ cục bộ trên mỗi máy trạm. Chia sẻ dữ liệu là một vấn đề khác nhau trong hầu hết các trường hợp. Điều đó loại bỏ một lý do lớn để sử dụng cơ sở dữ liệu.

Các ứng dụng GUI cũng có thể có các tài liệu phức tạp có thể được xử lý như một mạng lưới các đối tượng phức tạp trong bộ nhớ. Bình thường hóa cấu trúc thành một lược đồ DB quan hệ có thể làm tăng thêm độ phức tạp đáng kể cho vấn đề, đôi khi việc tuần tự hóa toàn bộ mọi thứ trong một lần tạm dừng sẽ dễ dàng hơn. Nhiều khung OOP bao gồm một số cơ sở chỉ cho điều đó.

Tuy nhiên, làm cho các tài liệu được lưu trữ có thể đọc được bằng các công cụ bên ngoài ứng dụng chính là một lợi thế lớn trong nhiều trường hợp, do đó, sử dụng các định dạng có thể đọc được của con người (XML, JSON, YAML, v.v.) hoặc một tệp zipfile kết hợp nhiều phần đơn giản hơn đang ngày càng nhiều hơn và phổ biến hơn.

Trên cùng một hướng, sử dụng một thư viện cơ sở dữ liệu có thể nhúng (BDB, Tokyo Cabin, SQLite, MS-SQL * server Compact, v.v.) là một cách tiếp cận tuyệt vời khác.

Cơ sở dữ liệu có thể quá mức cần thiết nhưng chúng thường không phải như vậy. Các chương trình rất đơn giản chỉ không cần chúng. Nếu tài liệu của bạn có thể tải lên bộ nhớ trong một khoảng thời gian không đáng kể và ở đó mà không gặp vấn đề gì, bạn không thực sự cần một chương trình cho nhiều chương trình.

Ví dụ: xem xét:

#include "superheader.h"

int main()
{
    int row=2, column=2;
    DatabaseType db;
    db.ConnectTo("programDB", "user", "pass");
    db.setTable("messages");
    string hello_world=db.fetch(row, column);
    cout<<hello_world;
    return 0;
}

Vâng, đó là quá đơn giản, nhưng rõ ràng điều này là quá nhiều. Không có điểm nào thực sự để có mức quản lý dữ liệu đó cho "Hello World"

Thông thường quy tắc ngón tay cái tôi sử dụng là sử dụng cơ sở dữ liệu nếu bạn có nhiều bộ dữ liệu, đặc biệt nếu chúng khác biệt HOẶC sử dụng cơ sở dữ liệu nếu lượng dữ liệu khá lớn. Cơ sở dữ liệu nói chung được liên kết với một số chi phí chung, nhưng có nhiều cơ sở dữ liệu không thực sự có nhiều. Chẳng hạn, cơ sở dữ liệu trong bộ nhớ nhỏ, nhẹ, đôi khi hữu ích cho các dự án nhỏ với quá trình xử lý nặng, lập lịch hoặc nhiều thay đổi động đối với dữ liệu.

Có nhiều kiểu mã hóa khác nhau, nhiều lần không có gì sai với cơ sở dữ liệu nhưng hầu hết chúng ta sẽ không đi "đến mức đó" cho các tác vụ cơ bản. Vẫn có những thời điểm khác cơ sở dữ liệu phù hợp sẽ cung cấp lợi ích hiệu suất. Cố gắng đặc biệt hiểu sự khác biệt về nơi dữ liệu sẽ ở đó, nó sẽ ở đó trong bao lâu và điều gì sẽ thay đổi nó trong suốt tuổi thọ của nó.

Sử dụng db luôn là điều đúng đắn và với việc triển khai SQLite cho thực tế mọi ngôn ngữ ngoài kia không sử dụng một ngôn ngữ chỉ là việc ra quyết định thiết kế kém. Lý do duy nhất để không sử dụng một là nếu bạn đang lập trình nhúng hoặc một số dạng lập trình không ứng dụng khác. Truy vấn dữ liệu và cài đặt bằng ngôn ngữ khai báo như SQL tự nhiên hơn nhiều so với truy cập các tệp phẳng hoặc các đối tượng khác trong bộ nhớ với cú pháp bắt buộc. Thêm vào đó, nó tách biệt rõ ràng các hoạt động dữ liệu với mã ứng dụng khác, về lâu dài làm cho mã trở nên mô đun và dễ bảo trì hơn.