Haruskah data statis disimpan dalam database atau di tempat lain?

Saya sedang mengerjakan beberapa perangkat lunak saat ini dan saya tidak yakin rute mana yang harus diambil. Saya punya beberapa data untuk disimpan di suatu tempat di perangkat seluler. Data tidak akan pernah berubah, dan memiliki hubungan hierarkis, dan akan digunakan untuk mengisi tampilan. Ada cukup banyak data ini.

Saya memiliki opsi berikut:

1. Satu set enum / objek
2. File XML
3. Basis data SQLite tertanam

Dalam kasus khusus ini saya berpikir bahwa opsi enums adalah yang paling tidak berfungsi, tetapi saya mendapatkan bau dari data yang tertanam dalam kode seperti itu.

File XML paling masuk akal menurut saya, tetapi menguraikannya akan menjadi sumber daya hit yang sepertinya sia-sia karena itu akan 'tidak pernah' berubah.

Basis data harus memberikan lebih sedikit hit kinerja, tetapi sepertinya berlebihan untuk data statis.

Jalur desain mana yang benar di sini?

Catatan: Dengan perubahan 'Tidak Pernah' Maksud saya jarang berubah. Data yang dimaksud adalah model dari serangkaian standar pemerintah, sehingga mereka mungkin berubah di beberapa titik di masa depan tetapi itu tidak akan secara teratur dan itu tidak akan secara otomatis memperbarui perangkat lunak kami baik sebagai perubahan dalam standar bisa baik memicu perubahan dalam persyaratan kami.

Saya akan menggunakan objek untuk ini.

Anda mengatakan data tidak akan pernah berubah, sehingga Anda dapat dengan mudah menyimpannya di aplikasi. Basis data akan berlebihan dan meningkatkan ukuran.
File XML akan agak berlebihan juga dan juga meningkatkan ukuran.

Jadi menurut saya pilihan terbaik adalah enum atau objek.

apakah itu tidak akan pernah berubah, atau itu akan berubah? Itulah pertanyaan yang harus Anda jawab sebelum mendapat respons yang baik.

Data statis yang tidak pernah berubah (mis. Nama hari dalam seminggu) baik untuk dimasukkan dalam kode;

Data yang praktis tidak pernah berubah (misalnya nama server Anda dns) juga baik untuk dimasukkan dalam kode, jika perlu diubah, itu sangat jarang sehingga pembaruan kode tidak masalah.

Data yang tidak berubah, tetapi mungkin (mis. Waktu tunda antara pembaruan berkala) mungkin terbaik di lokasi yang mudah diubah, seperti toko konfigurasi lokal (sqlite atau xml, tidak membuat perbedaan nyata)

Penyimpanan tidak terlalu diperhatikan - jika tidak pernah atau hampir tidak pernah berubah, Anda dapat membacanya semuanya di awal program dan menyimpannya sebagai data program. Jika, seandainya hal itu memang perlu diubah, restart aplikasi bukan masalah besar.

Biasanya hal-hal yang "tidak pernah berubah" adalah yang pertama kali berubah ...
Apakah Anda menggunakan database atau sistem eksternal lainnya (seperti file konfigurasi) tidak banyak berarti, asalkan itu dapat dengan mudah dan cepat diakses saat dibutuhkan.
Saya cenderung menggunakan tabel database jika saya sudah memiliki database, dan itu masuk akal (katakanlah data mungkin perlu diubah oleh orang-orang yang tidak memiliki akses sistem file ke server aplikasi digunakan, atau berjalan di beberapa mesin dan konfigurasi harus tetap selaras di antara mereka).
Tentu saja basis data tidak bisa menampung semuanya. Kredensial database misalnya perlu disimpan di tempat lain, kemungkinan besar file konfigurasi.

Pertanyaan untuk meminta data apa pun bukanlah apakah itu akan berubah; Anda mungkin tidak tahu, dan bahkan jika Anda tahu, jawabannya mungkin akan menyesatkan.

Pertanyaan yang harus ditanyakan adalah, ketika itu berubah, siapa yang harus mengubahnya:

• penulis perangkat lunak: masukkan ke dalam kode
• pengguna akhir: memiliki opsi pada GUI
• orang lain (mis. integrator sistem, layanan internasionalisasi, dll.): tabel basis data, file atau apa pun yang masuk akal (termasuk terkadang API ekstensi).

Selasa umumnya harus menjadi enum bukan karena tidak pernah bisa berubah. Tetapi karena jika seorang diktator gila mengambil alih dan menuntut nama Selasa untuknya, Anda sebagai pembuat perangkat lunak harus mengubahnya (atau diumpankan ke hiu).

Anda tidak ingin semua pengguna Anda harus menggali file konfigurasi atau tabel database yang tidak jelas untuk menghindari nasib itu ...

Ada kemungkinan data "Anda" mungkin perlu diubah meskipun entitas yang diwakili oleh data di dunia nyata mungkin tidak. Anda perlu memutuskan apakah layak untuk menyertakan file teks terpisah dari beberapa jenis yang dapat diperbarui tanpa memperbarui seluruh aplikasi.

Contoh:

1. Kesalahan tipografi / salah mengeja.
2. Kelalaian tidak sengaja.
3. Tawarkan data dalam bahasa lain.
4. Menawarkan cara bagi pengguna untuk melakukan perubahan mereka sendiri.

Jenis lain dari perubahan struktur data mungkin perlu pembaruan ke aplikasi, jadi itu tidak ada manfaatnya.

Saya awalnya menulis jawaban ini untuk pertanyaan ini pada stackoverflow , tetapi saya pikir jawaban yang sama berlaku untuk pertanyaan ini juga.

Ada sebuah artikel oleh Mathias Verraes yang membahas masalah Anda di sini . Dia berbicara tentang Memisahkan objek nilai dalam model dari konsep yang melayani UI.

Mengutip dari artikel ketika ditanya apakah akan memodelkan Negara sebagai entitas atau objek nilai:

Secara intrinsik tidak ada yang salah dengan memodelkan negara sebagai entitas dan menyimpannya dalam basis data. Tetapi dalam banyak kasus, hal-hal yang terlalu rumit. Negara tidak sering berubah. Ketika nama suatu negara berubah, sebenarnya, untuk semua tujuan praktis, sebuah negara baru. Jika suatu negara suatu hari tidak ada lagi, Anda tidak bisa begitu saja mengubah semua alamat, karena mungkin negara itu dibagi menjadi dua negara.

Dia menyarankan pendekatan berbeda untuk memperkenalkan konsep baru yang disebut AvailableCountry:

Negara-negara yang tersedia ini dapat berupa entitas dalam database, catatan dalam JSON, atau bahkan hanya daftar yang dikodekan dalam kode Anda. (Itu tergantung pada apakah bisnis menginginkan akses mudah ke mereka melalui UI.)

<?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];
    }
}

Jadi sepertinya ada solusi ke-3 yang memodelkan mencari tabel sebagai objek nilai dan entitas.

BTW pastikan Anda memeriksa bagian komentar untuk beberapa diskusi serius tentang artikel ini.

Hal yang perlu dipertimbangkan:

• Seberapa statis data itu? Jika itu tidak akan pernah berubah, maka itu harus hidup di objek. Untuk mengubah data, Anda mungkin harus mengkompilasi ulang dan memindahkan kembali. Apakah Anda senang melakukan pemindahan untuk perubahan kecil?

• Jika itu adalah aplikasi web dan Anda memilikinya sebagai bagian dari web.config, apakah Anda senang dengan aplikasi memulai kembali ketika Anda membuat perubahan pada data itu?

• Jika Anda memasukkannya ke dalam basis data, Anda dapat selalu menyimpannya di sisi klien (aplikasi desktop) atau sisi server (layanan atau situs web). Basis data mungkin merupakan solusi IMO yang bagus.