Dữ liệu tĩnh nên được lưu trữ trong cơ sở dữ liệu hoặc một nơi nào khác?

Tôi đang làm việc trên một số phần mềm tại thời điểm này và tôi không chắc chắn nên chọn con đường nào với việc này. Tôi có một số dữ liệu để lưu trữ ở đâu đó trên thiết bị di động. Dữ liệu sẽ không bao giờ thay đổi và có mối quan hệ phân cấp và sẽ được sử dụng để điền vào màn hình. Có một lượng hợp lý của dữ liệu này.

Tôi có các tùy chọn sau:

1. Một tập hợp các enums / object
2. Một tệp XML
3. Cơ sở dữ liệu SQLite nhúng

Trong trường hợp cụ thể này, tôi nghĩ rằng tùy chọn enums là công việc ít nhất, nhưng tôi nhận được mùi từ dữ liệu được nhúng trong mã như thế.

Tôi nghĩ rằng tệp XML có ý nghĩa nhất, nhưng phân tích cú pháp nó sẽ là một cú đánh tài nguyên có vẻ như là một sự lãng phí vì nó sẽ 'không bao giờ' thay đổi.

Cơ sở dữ liệu sẽ cung cấp ít hơn một lần nhấn hiệu năng, nhưng có vẻ như quá mức cần thiết cho dữ liệu tĩnh.

Đó là con đường thiết kế chính xác ở đây?

Lưu ý: Bởi 'Không bao giờ thay đổi' Tôi có nghĩa là nó sẽ hiếm khi thay đổi. Dữ liệu được đề cập là một mô hình của một bộ các tiêu chuẩn của chính phủ, vì vậy chúng có thể sẽ thay đổi vào một thời điểm nào đó trong tương lai nhưng nó sẽ không thường xuyên và nó sẽ không tự động cập nhật phần mềm của chúng tôi vì sự thay đổi trong các tiêu chuẩn cũng có thể kích hoạt một sự thay đổi trong yêu cầu của chúng tôi.

Tôi sẽ sử dụng một đối tượng cho việc này.

Bạn cho biết dữ liệu sẽ không bao giờ thay đổi, vì vậy bạn có thể dễ dàng lưu trữ nó trong ứng dụng. Cơ sở dữ liệu sẽ quá mức cần thiết và tăng kích thước.
Tệp XML cũng sẽ quá mức cần thiết và cũng làm tăng kích thước.

Vì vậy, theo tôi, lựa chọn tốt nhất sẽ là enum hoặc object.

nó sẽ không bao giờ thay đổi, hay nó sẽ thay đổi? Đó là câu hỏi bạn thực sự phải trả lời trước khi nhận được phản hồi tốt.

Dữ liệu tĩnh không bao giờ thay đổi (ví dụ: ngày trong tuần) là mã tốt;

Dữ liệu thực tế không bao giờ thay đổi (ví dụ tên máy chủ của bạn) cũng rất tốt để nhập mã, nếu cần thay đổi, rất hiếm khi cập nhật mã là ok.

Dữ liệu không thay đổi, nhưng có thể (ví dụ: thời gian trễ giữa các lần làm mới định kỳ) có lẽ là tốt nhất ở một vị trí dễ thay đổi, chẳng hạn như cửa hàng cấu hình cục bộ (sqlite hoặc xml, không có sự khác biệt thực sự)

Việc lưu trữ là một mối quan tâm nhỏ - nếu nó không bao giờ hoặc hầu như không bao giờ thay đổi, bạn có thể đọc tất cả trong lúc bắt đầu chương trình và lưu trữ nó dưới dạng dữ liệu chương trình. Nếu, trong trường hợp không thể xảy ra, nó cần phải thay đổi, thì việc khởi động lại ứng dụng không phải là vấn đề lớn.

Thông thường, những thứ "không bao giờ thay đổi" là thứ đầu tiên thay đổi ...
Cho dù bạn sử dụng cơ sở dữ liệu hay một số hệ thống bên ngoài khác (như tệp cấu hình) ít quan trọng, miễn là có thể dễ dàng và nhanh chóng truy cập khi cần.
Tôi có xu hướng sử dụng bảng cơ sở dữ liệu nếu tôi đã có cơ sở dữ liệu và điều này hợp lý (giả sử nhu cầu dữ liệu có thể được thay đổi bởi những người không có quyền truy cập hệ thống tệp vào máy chủ mà ứng dụng được triển khai hoặc chạy trên nhiều máy và cấu hình cần phải được giữ đồng bộ giữa chúng).
Tất nhiên một cơ sở dữ liệu không thể chứa mọi thứ. Ví dụ, thông tin cơ sở dữ liệu sẽ cần được lưu trữ ở nơi khác, rất có thể là tệp cấu hình.

Câu hỏi để hỏi về bất kỳ dữ liệu nào không phải là liệu nó có thay đổi hay không; bạn có thể không biết, và ngay cả khi bạn đã làm, câu trả lời có thể sẽ gây hiểu nhầm.

Câu hỏi cần đặt ra là, khi nó thay đổi, ai nên thay đổi nó:

• tác giả phần mềm: đặt nó vào mã
• người dùng cuối: có một tùy chọn trên GUI
• người khác (ví dụ: nhà tích hợp hệ thống, dịch vụ quốc tế hóa, v.v.): bảng cơ sở dữ liệu, tệp hoặc bất cứ điều gì có ý nghĩa (bao gồm cả đôi khi là một API mở rộng).

Thứ ba nói chung nên là một enum không phải vì nó không bao giờ có thể thay đổi. Nhưng bởi vì nếu một nhà độc tài điên rồ đã chịu trách nhiệm và yêu cầu thứ ba được đặt theo tên anh ta, thì bạn với tư cách là tác giả phần mềm sẽ phải thay đổi nó (hoặc được cho cá mập ăn).

Bạn sẽ không muốn tất cả người dùng của mình phải đào sâu vào các tệp cấu hình hoặc các bảng cơ sở dữ liệu tối nghĩa để tránh số phận đó ...

Có khả năng dữ liệu "của bạn" có thể cần thay đổi mặc dù các thực thể mà dữ liệu đại diện trong thế giới thực có thể không. Bạn cần phải quyết định xem có đáng để đưa vào một tệp văn bản riêng có thể được cập nhật mà không cần cập nhật toàn bộ ứng dụng hay không.

Ví dụ:

1. Lỗi đánh máy / lỗi chính tả.
2. Thiếu sót tình cờ.
3. Cung cấp dữ liệu bằng ngôn ngữ khác.
4. Cung cấp một cách để người dùng thực hiện các thay đổi của riêng họ.

Bất kỳ loại thay đổi cấu trúc dữ liệu nào khác có thể sẽ cần cập nhật cho ứng dụng, vì vậy điều đó không có lợi.

Ban đầu tôi đã viết câu trả lời này cho câu hỏi này trên stackoverflow , nhưng tôi nghĩ câu trả lời tương tự cũng áp dụng cho câu hỏi này.

Có một bài viết của Mathias Verraes nói về vấn đề của bạn ở đây . Ông nói về việc tách các đối tượng giá trị trong mô hình khỏi các khái niệm phục vụ UI.

Trích dẫn từ bài viết khi được hỏi liệu mô hình hóa Quốc gia thành đối tượng hoặc đối tượng giá trị:

Về bản chất, không có gì sai với các quốc gia mô hình hóa như các thực thể và lưu trữ chúng trong cơ sở dữ liệu. Nhưng trong hầu hết các trường hợp, điều đó quá phức tạp. Các quốc gia không thay đổi thường xuyên. Khi tên một quốc gia thay đổi, thực tế, cho tất cả các mục đích thực tế, một quốc gia mới. Nếu một quốc gia một ngày không còn tồn tại nữa, bạn không thể thay đổi tất cả các địa chỉ, vì có thể quốc gia đó được chia thành hai quốc gia.

Ông đề xuất một cách tiếp cận khác để giới thiệu một khái niệm mới gọi là AvailableCountry:

Các quốc gia có sẵn này có thể là các thực thể trong cơ sở dữ liệu, các bản ghi trong JSON hoặc thậm chí đơn giản là một danh sách được mã hóa cứng trong mã của bạn. (Điều đó phụ thuộc vào việc doanh nghiệp có muốn truy cập dễ dàng vào họ thông qua UI hay không.)

<?php

final class Country
{
    private $countryCode;

    public function __construct($countryCode)
    {
        $this->countryCode = $countryCode;
    }

    public function __toString()
    {
        return $this->countryCode;
    }
}

final class AvailableCountry
{
    private $country;
    private $name;

    public function __construct(Country $country, $name)
    {
        $this->country = $country;
        $this->name = $name;
    }

    /** @return Country */
    public function getCountry()
    {
        return $this->country;
    }

    public function getName()
    {
        return $this->name;
    }

}

final class AvailableCountryRepository
{
    /** @return AvailableCountry[] */
    public function findAll()
    {
        return [
            'BE' => new AvailableCountry(new Country('BE'), 'Belgium'),
            'FR' => new AvailableCountry(new Country('FR'), 'France'),
            //...
        ];
    }

    /** @return AvailableCountry */
    public function findByCountry(Country $country)
    {
        return $this->findAll()[(string) $country];
    }
}

Vì vậy, có vẻ như có một giải pháp thứ 3 là mô hình tra cứu các bảng dưới dạng cả đối tượng và thực thể giá trị.

BTW đảm bảo bạn kiểm tra phần bình luận cho một số cuộc thảo luận nghiêm túc về bài viết.

Những điều cần cân nhắc:

• Làm thế nào tĩnh là dữ liệu? Nếu nó sẽ không bao giờ thay đổi, thì nó sẽ sống trong đối tượng. Để thay đổi dữ liệu, bạn có thể phải biên dịch lại và triển khai lại. Bạn có hài lòng với việc thực hiện tái triển khai cho một thay đổi nhỏ không?

• Nếu đó là một ứng dụng web và bạn có nó như một phần của web.config, bạn có hài lòng với việc khởi động lại ứng dụng khi bạn thay đổi dữ liệu đó không?

• Nếu bạn đặt nó vào cơ sở dữ liệu, bạn luôn có thể lưu trữ bộ đệm đó ở phía máy khách (ứng dụng máy tính để bàn) hoặc phía máy chủ (dịch vụ hoặc trang web). Cơ sở dữ liệu có thể là một giải pháp tốt IMO.