Чи повинні статичні дані зберігатися в базі даних чи десь ще?

На даний момент я працюю над деяким програмним забезпеченням, і я не впевнений, який шлях для цього взяти. У мене є деякі дані для зберігання десь на мобільному пристрої. Дані ніколи не змінюватимуться і мають ієрархічну залежність і будуть використовуватися для заповнення відображення. Ці дані є досить обґрунтованими.

У мене є такі варіанти:

1. Набір переліків / об’єктів
2. XML-файл
3. Вбудована база даних SQLite

У цьому конкретному випадку я вважаю, що варіант перерахунків - це найменша робота, але я відчуваю запах від даних, вбудованих у такий код.

XML-файл має найбільш сенс, я думаю, але його аналіз буде хітом ресурсу, який здається марним, оскільки він ніколи не зміниться.

База даних повинна забезпечити менший показник ефективності, але здається, що це статичне перевищення статичних даних.

Який тут правильний шлях дизайну?

Примітка: "Ніколи" не маю на увазі, що це буде рідко змінюватися. Дані, про які йдеться, є моделлю набору державних стандартів, тому вони можуть змінитися в якийсь момент у майбутньому, але це не буде регулярно, і його автоматичне оновлення не буде автоматично оновлено, оскільки зміна стандартів цілком може викликати зміну наших вимог.

Я б для цього використовував об’єкт.

Ви сказали, що дані ніколи не зміняться, тому ви можете легко зберігати їх у додатку. База даних буде надмірною і збільшить її розмір.
XML-файл теж був би надмірним, а також збільшує розмір.

Тож, на мою думку, найкращим варіантом буде перерахунок або об’єкт.

це ніколи не зміниться, чи зміниться? Це питання, на яке ви дійсно повинні відповісти, перш ніж отримати хорошу відповідь.

Статичні дані, які ніколи не змінюються (наприклад, назви днів тижня), корисно вводити код;

Дані, які практично ніколи не змінюються (наприклад, ім’я dns вашого сервера), також добре вводити код, якщо він потребує змін, його настільки рідко, що оновлення коду нормально.

Дані, які не змінюються, але можуть (наприклад, затримка часу між періодичними оновленнями), мабуть, найкращі в легко міняному місці, наприклад, локальному сховищі конфігурацій (sqlite або xml, не має жодної реальної різниці)

Зберігання не викликає занепокоєння - якщо воно ніколи або майже ніколи не змінюється, ви можете прочитати все це при запуску програми та кешувати їх як дані програми. Якщо, навряд чи, коли-небудь це потрібно змінити, перезавантаження програми не є великою справою.

Зазвичай речі, які "ніколи не змінюються", першими змінюються ...
Незалежно від того, чи використовуєте ви базу даних чи якусь іншу зовнішню систему (наприклад, файл конфігурації), мало важливо, доки до неї можна легко та швидко отримати доступ, коли це потрібно.
Я схильний використовувати таблицю баз даних, якщо у мене вже є база даних, і це має сенс (скажімо, дані можуть бути змінені людьми, які не мають доступу до файлової системи до сервера, до якого розгорнута програма, або вона працює на декількох машинах і конфігурацію потрібно зберігати синхронно між ними).
Звичайно, база даних не може вмістити все. Наприклад, облікові дані бази даних повинні бути збережені в іншому місці, швидше за все, у файлі конфігурації.

Питання, щоб задати будь-які дані, полягає не в тому, чи зміняться вони; ви, мабуть, не знаєте, і навіть якби ви це зробили, відповідь, ймовірно, буде вводити в оману.

Питання, яке потрібно задати, коли він змінюється, хто повинен його змінити:

• автор програмного забезпечення: помістіть його в код
• кінцевий користувач: мати опцію на графічному інтерфейсі
• хтось інший (наприклад, системний інтегратор, служба інтернаціоналізації тощо): таблиця бази даних, файл або будь-який сенс (включаючи іноді API розширення).

Вівторок, як правило, повинен бути перерахунком, тому що він ніколи не може змінитися. Але оскільки якщо божевільний диктатор взяв на себе відповідальність і вимагатиме вівторок назвати його ім'ям, то вам, як автору програмного забезпечення, доведеться його змінити (або подати акулам).

Ви б не хотіли, щоб усі ваші користувачі перекопувались у конфігураційні файли чи неясні таблиці баз даних, щоб уникнути такої долі ...

Є ймовірність "ваших" даних, можливо, знадобиться змінити, навіть якщо сутності, які дані представляють у реальному світі, можуть не мати. Вам потрібно вирішити, чи варто йому включити окремий текстовий файл якогось типу, який можна оновити без оновлення всього додатка.

Приклади:

1. Друкарська помилка / неправильне написання.
2. Випадкове упущення.
3. Запропонуйте дані іншою мовою.
4. Запропонуйте користувачеві спосіб внести власні зміни.

Будь-який інший тип зміни структури даних, ймовірно, потребуватиме оновлення програми, тому це не принесе користі.

Я спочатку написав відповідь на це питання на stackoverflow , але думаю, що ця ж відповідь стосується і цього питання.

Є стаття Матіаса Верраса, яка розповідає про вашу проблему тут . Він розповідає про відокремлення об'єктів цінності в моделі від понять, які обслуговують інтерфейс користувача.

Цитуючи із статті, коли його запитують, чи можна моделювати Країни як сутність чи ціннісний об'єкт:

З моделюючими країнами як сутностями та зберіганням їх у базі даних немає нічого суттєвого. Але в більшості випадків це надто ускладнює речі. Країни змінюються не часто. Коли назва країни змінюється, це фактично для всіх практичних цілей нова країна. Якщо країни одного дня більше не існує, ви не можете просто змінити всі адреси, тому що, можливо, країна була розділена на дві країни.

Він запропонував інший підхід до впровадження нової концепції під назвою AvailableCountry:

Ці доступні країни можуть бути суб'єктами в базі даних, записами в JSON або навіть просто жорстким кодом у вашому коді. (Це залежить від того, чи хоче бізнес легко отримати доступ до них через інтерфейс користувача.)

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

Тож, здається, існує третє рішення, яке полягає в моделюванні пошуку таблиць як об'єктів цінності, так і об'єктів.

BTW переконайтеся, що ви перегляньте розділ коментарів для серйозних дискусій щодо статті.

Що слід врахувати:

• Наскільки статичні дані? Якщо він ніколи не зміниться, він повинен жити в об'єкті. Щоб змінити дані, можливо, вам доведеться перекомпілювати та повторно розмістити. Чи задоволені ви тим, що зробили перепланування для незначних змін?

• Якщо це веб-додаток, і він є частиною web.config, чи задоволений ви перезавантаження програми, коли вносите зміни до цих даних?

• Якщо ви помістите його в базу даних, ви завжди можете кешувати її на стороні клієнта (настільний додаток) або сервера (сервіс або веб-сайт). База даних може бути хорошим рішенням IMO.