ข้อมูลคงที่ควรถูกเก็บไว้ในฐานข้อมูลหรือที่อื่น?

ฉันกำลังทำงานกับซอฟต์แวร์บางอย่างในขณะนี้และฉันไม่แน่ใจว่าจะใช้เส้นทางนี้กับอะไร ฉันมีข้อมูลบางอย่างเพื่อเก็บไว้ที่ไหนสักแห่งบนอุปกรณ์มือถือ ข้อมูลจะไม่เปลี่ยนแปลงและมีความสัมพันธ์แบบลำดับชั้นและจะใช้ในการเติมการแสดงผล ข้อมูลนี้มีจำนวนพอสมควร

ฉันมีตัวเลือกดังต่อไปนี้:

1. ชุดของ enums / วัตถุ
2. ไฟล์ XML
3. ฐานข้อมูล SQLite แบบฝัง

ในกรณีพิเศษนี้ฉันคิดว่าตัวเลือก enums นั้นใช้งานได้น้อยที่สุด แต่ฉันได้กลิ่นจากข้อมูลที่ฝังอยู่ในโค้ดเช่นนั้น

ไฟล์ XML เหมาะสมที่สุดที่ฉันคิด แต่การแยกวิเคราะห์จะเป็นแหล่งข้อมูลที่ดูเหมือนว่าเสียเพราะจะไม่มีการเปลี่ยนแปลง

ฐานข้อมูลควรให้ประสิทธิภาพการทำงานน้อยลง แต่ดูเหมือนว่า overkill สำหรับข้อมูลคงที่

เส้นทางการออกแบบที่ถูกต้องที่นี่คืออะไร?

หมายเหตุ:การเปลี่ยนแปลง 'ไม่' ฉันหมายถึงว่ามันจะไม่ค่อยเปลี่ยนแปลง ข้อมูลที่เป็นปัญหานั้นเป็นแบบจำลองของมาตรฐานรัฐบาลดังนั้นอาจมีการเปลี่ยนแปลงในบางจุดในอนาคต แต่จะไม่เป็นประจำและจะไม่อัปเดตซอฟต์แวร์ของเราโดยอัตโนมัติเมื่อการเปลี่ยนแปลงมาตรฐานทำได้ดี ก่อให้เกิดการเปลี่ยนแปลงในข้อกำหนดของเรา

ฉันจะใช้วัตถุสำหรับสิ่งนี้

คุณกล่าวว่าข้อมูลจะไม่เปลี่ยนแปลงดังนั้นคุณสามารถจัดเก็บไว้ในแอปพลิเคชันได้อย่างง่ายดาย ฐานข้อมูลจะ overkill และเพิ่มขนาด
ไฟล์ XML จะเป็นแบบ overkill ด้วยเช่นกันและยังเพิ่มขนาด

ดังนั้นในความคิดของฉันตัวเลือกที่ดีที่สุดจะเป็น enum หรือวัตถุ

มันจะไม่เปลี่ยนแปลงหรือจะเปลี่ยน? นั่นเป็นคำถามที่คุณต้องตอบก่อนที่จะได้รับการตอบรับที่ดี

ข้อมูลสแตติกที่ไม่เปลี่ยนแปลง (เช่นชื่อวันในสัปดาห์) เป็นโค้ดที่ดี

ข้อมูลที่ไม่เคยเปลี่ยนแปลง (เช่นชื่อเซิร์ฟเวอร์ DNS ของคุณ) ก็เป็นเรื่องที่ดีหากคุณต้องการเปลี่ยนรหัสหากจำเป็นต้องเปลี่ยนแปลงก็ยากที่จะอัปเดตรหัสได้

ข้อมูลที่ไม่เปลี่ยนแปลง แต่อาจ (เช่นการหน่วงเวลาระหว่างการรีเฟรชเป็นระยะ) น่าจะดีที่สุดในตำแหน่งที่เปลี่ยนแปลงได้ง่ายเช่น local config store (sqlite หรือ xml ทำให้ไม่แตกต่างกันจริง)

ที่เก็บข้อมูลมีความกังวลเล็กน้อย - ถ้ามันไม่เคยเปลี่ยนแปลงหรือแทบจะไม่เคยเปลี่ยนแปลงเลยคุณสามารถอ่านมันได้ตั้งแต่เริ่มโปรแกรมและแคชเป็นข้อมูลโปรแกรม หากในกรณีที่ไม่จำเป็นต้องมีการเปลี่ยนแปลงการรีสตาร์ทแอพไม่ใช่เรื่องใหญ่

โดยทั่วไปสิ่งที่ "ไม่เปลี่ยนแปลง" เป็นคนแรกที่เปลี่ยน ...
ไม่ว่าคุณจะใช้ฐานข้อมูลหรือระบบภายนอกอื่น ๆ (เช่นไฟล์กำหนดค่า) มีความสำคัญเล็กน้อยตราบใดที่สามารถเข้าถึงได้ง่ายและรวดเร็วเมื่อจำเป็น
ฉันมักจะใช้ตารางฐานข้อมูลถ้าฉันมีฐานข้อมูลอยู่แล้วและเหมาะสม (กล่าวว่าข้อมูลที่ต้องการอาจมีการเปลี่ยนแปลงโดยผู้ที่ไม่มีการเข้าถึงระบบไฟล์ไปยังเซิร์ฟเวอร์ที่มีการปรับใช้แอปพลิเคชันหรือทำงานบนเครื่องหลายเครื่อง และการกำหนดค่าจะต้องเก็บไว้ในซิงค์ระหว่างพวกเขา)
แน่นอนฐานข้อมูลไม่สามารถเก็บทุกอย่างได้ ตัวอย่างเช่นการรับรองฐานข้อมูลจะต้องจัดเก็บไว้ที่อื่นซึ่งส่วนใหญ่เป็นไฟล์การกำหนดค่า

คำถามที่ถามถึงข้อมูลใด ๆ ไม่ว่าจะเปลี่ยนแปลงหรือไม่ คุณอาจไม่รู้และแม้ว่าคุณทำคำตอบก็น่าจะทำให้เข้าใจผิด

คำถามที่ถามคือเมื่อมีการเปลี่ยนแปลงใครควรเปลี่ยน:

• ผู้เขียนซอฟต์แวร์: ใส่ไว้ในรหัส
• ผู้ใช้ปลายทาง: มีตัวเลือกบน GUI
• บุคคลอื่น (เช่นผู้รวบรวมระบบ, บริการระหว่างประเทศ, ฯลฯ ): ตารางฐานข้อมูล, ไฟล์หรืออะไรก็ตามที่เหมาะสม

โดยทั่วไปแล้ววันอังคารควรเป็นเงินไม่ใช่เพราะมันไม่สามารถเปลี่ยนแปลงได้ แต่เพราะหากเผด็จการคนบ้าได้รับการตั้งชื่อและเรียกร้องในวันอังคารคุณจะต้องเปลี่ยนชื่อคุณเป็นผู้เขียนซอฟต์แวร์

คุณไม่ต้องการให้ผู้ใช้ทุกคนต้องขุดลงไปในไฟล์ config หรือปิดบังตารางฐานข้อมูลเพื่อหลีกเลี่ยงชะตากรรมนั้น ...

มีโอกาส "ข้อมูล" ของคุณอาจจำเป็นต้องเปลี่ยนแปลงแม้ว่าเอนทิตีที่ข้อมูลแสดงในโลกแห่งความเป็นจริงอาจไม่ คุณต้องตัดสินใจว่ามันคุ้มค่าหรือไม่ที่จะรวมไฟล์ข้อความแยกประเภทบางประเภทที่สามารถอัปเดตได้โดยไม่ต้องอัปเดตแอปทั้งหมด

ตัวอย่าง:

1. ข้อผิดพลาดในการพิมพ์ / การสะกดผิด
2. การละเลยโดยไม่ตั้งใจ
3. เสนอข้อมูลเป็นภาษาอื่น
4. เสนอวิธีการสำหรับผู้ใช้ในการเปลี่ยนแปลงของตัวเอง

การเปลี่ยนแปลงโครงสร้างข้อมูลประเภทอื่น ๆ อาจต้องมีการอัพเดทแอพดังนั้นจึงไม่มีประโยชน์

ฉันเดิมเขียนคำตอบนี้สำหรับคำถามนี้ใน stackoverflowแต่ฉันคิดว่าคำตอบเดียวกันนี้สำหรับคำถามนี้ด้วย

มีบทความโดยเป็นงัด Verraesที่พูดคุยเกี่ยวกับปัญหาของคุณได้ที่นี่ เขาพูดถึงการแยกวัตถุที่มีค่าในรูปแบบจากแนวคิดที่ให้บริการ UI

การอ้างอิงจากบทความเมื่อถูกถามว่าจะจำลองประเทศเป็นนิติบุคคลหรือวัตถุค่า:

ไม่มีอะไรผิดปกติกับการสร้างแบบจำลองประเทศในฐานะหน่วยงานและเก็บไว้ในฐานข้อมูล แต่ในกรณีส่วนใหญ่สิ่งที่ซับซ้อนเกินไป ประเทศไม่เปลี่ยนแปลงบ่อย เมื่อชื่อประเทศเปลี่ยนไปจริง ๆ แล้วเป็นประเทศใหม่ หากไม่มีวันหนึ่งประเทศอีกต่อไปคุณจะไม่สามารถเปลี่ยนที่อยู่ทั้งหมดได้เนื่องจากประเทศนั้นอาจถูกแบ่งออกเป็นสองประเทศ

เขาเสนอแนวทางที่แตกต่างเพื่อแนะนำแนวคิดใหม่ที่เรียกว่าAvailableCountry:

ประเทศที่มีเหล่านี้สามารถเป็นเอนทิตีในฐานข้อมูลบันทึกใน JSON หรือแม้แต่รายการฮาร์ดโค้ดในรหัสของคุณ (ขึ้นอยู่กับว่าธุรกิจต้องการเข้าถึงได้ง่ายผ่าน 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];
    }
}

ดังนั้นดูเหมือนว่าจะมีวิธีที่ 3 ซึ่งเป็นแบบจำลองการค้นหาตารางเป็นทั้งวัตถุค่าและเอนทิตี

BTW ตรวจสอบให้แน่ใจว่าคุณตรวจสอบส่วนความเห็นสำหรับการสนทนาอย่างจริงจังเกี่ยวกับบทความ

สิ่งที่ต้องพิจารณา:

• ข้อมูลเป็นอย่างไร ถ้ามันจะไม่มีวันเปลี่ยนแปลงมันควรจะมีชีวิตอยู่ในวัตถุ ในการเปลี่ยนข้อมูลคุณอาจต้องรวบรวมและปรับใช้ใหม่ คุณมีความสุขกับการปรับใช้การเปลี่ยนแปลงเล็กน้อยหรือไม่?

• หากเป็นแอปพลิเคชันบนเว็บและคุณได้เป็นส่วนหนึ่งของ web.config คุณมีความสุขกับการรีสตาร์ทแอปพลิเคชันเมื่อคุณทำการเปลี่ยนแปลงข้อมูลนั้นหรือไม่?

• หากคุณใส่ลงในฐานข้อมูลคุณสามารถแคชไว้ที่ฝั่งไคลเอ็นต์ (แอปพลิเคชันเดสก์ท็อป) หรือฝั่งเซิร์ฟเวอร์ (บริการหรือเว็บไซต์) ฐานข้อมูลอาจเป็นทางออกที่ดี IMO