Должны ли статические данные храниться в базе данных или где-то еще?

Сейчас я работаю над некоторыми программами, и я не уверен, какой путь выбрать для этого. У меня есть данные для хранения на мобильном устройстве. Данные никогда не изменятся и имеют иерархическую связь, и будут использоваться для заполнения дисплея. Существует достаточное количество этих данных.

У меня есть следующие варианты:

1. Набор перечислений / объектов
2. XML-файл
3. Встроенная база данных SQLite

В этом конкретном случае я думаю, что опция enums - это наименьшая работа, но я чувствую запах от данных, встроенных в код, подобный этому.

Я думаю, что XML-файл имеет больше смысла, но его разбор будет попаданием ресурсов, которое кажется пустой тратой, поскольку «никогда» не изменится.

База данных должна обеспечивать меньшее снижение производительности, но похоже на избыточность статических данных.

Какой правильный путь дизайна здесь?

Примечание. Под словом «Никогда» я подразумеваю, что оно будет меняться редко. Данные данные являются моделью набора государственных стандартов, поэтому они могут измениться в какой-то момент в будущем, но не будут регулярно и не будут автоматически обновлять наше программное обеспечение, так как изменение стандартов вполне может вызвать изменение наших требований.

Я бы использовал объект для этого.

Вы сказали, что данные никогда не изменятся, поэтому вы можете легко сохранить их в приложении. База данных будет излишней и увеличит размер.
Файл XML тоже может быть излишним, а также увеличивает его размер.

Поэтому, на мой взгляд, лучшим вариантом будет перечисление или объект.

это никогда не изменится, или это изменится? Это вопрос, на который вы действительно должны ответить, прежде чем получите хороший ответ.

Статические данные, которые никогда не меняются (например, названия дней недели), хорошо использовать в коде;

Данные, которые практически никогда не меняются (например, DNS-имя вашего сервера), также хороши для добавления в код, если его нужно изменить, настолько редко, что обновление кода в порядке.

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

Хранение не имеет большого значения - если оно никогда или почти никогда не изменяется, вы можете прочитать все это при запуске программы и кэшировать как данные программы. Если в маловероятном случае, когда это когда-либо нужно будет изменить, перезапуск приложения не так уж и важен.

Обычно вещи, которые «никогда не меняются», меняются первыми…
Используете ли вы базу данных или какую-либо другую внешнюю систему (например, файл конфигурации), не имеет большого значения, если к ней можно легко и быстро получить доступ при необходимости.
Я склонен использовать таблицу базы данных, если у меня уже есть база данных в любом случае, и это имеет смысл (скажем, данные могут быть изменены людьми, у которых нет доступа к файловой системе на сервере, на котором развернуто приложение, или оно работает на нескольких компьютерах и конфигурация должна быть синхронизирована между ними).
Конечно, база данных не может содержать все. Например, учетные данные базы данных необходимо хранить в другом месте, скорее всего, в файле конфигурации.

Вопрос для любых данных заключается не в том, изменится ли он; вы, вероятно, не знаете, и даже если бы вы сделали, ответ, вероятно, будет вводить в заблуждение.

Вопрос, который нужно задать, когда он меняется, кто должен его изменить:

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

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

Вы бы не хотели, чтобы все ваши пользователи копались в конфигурационных файлах или скрывали таблицы базы данных, чтобы избежать этой участи ...

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

Примеры:

1. Опечатка / опечатка.
2. Случайное упущение.
3. Предложите данные на другом языке.
4. Предложите пользователю возможность вносить свои изменения.

Любое другое изменение структуры данных, вероятно, потребует обновления приложения, так что это не принесет пользы.

Первоначально я написал этот ответ на этот вопрос на stackoverflow , но я думаю, что тот же ответ относится и к этому вопросу.

Существует статья Матиаса Verraes , что говорит о вашей проблеме здесь . Он говорит об отделении объектов-значений в модели от концепций, которые служат пользовательскому интерфейсу.

Цитата из статьи, когда ее спрашивают, следует ли моделировать страны как объекты или объекты стоимости:

Нет ничего плохого в том, чтобы моделировать страны как объекты и хранить их в базе данных. Но в большинстве случаев это усложняет вещи. Страны меняются не часто. Когда название страны меняется, это фактически для всех практических целей новая страна. Если однажды страны больше не существует, вы не можете просто изменить все адреса, потому что, возможно, страна была разделена на две страны.

Он предложил другой подход для введения новой концепции под названием 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];
    }
}

Таким образом, кажется, есть третье решение, которое заключается в моделировании таблиц поиска как объектов-значений, так и объектов.

Кстати, убедитесь, что вы проверили раздел комментариев для серьезных обсуждений этой статьи.

Что нужно учитывать:

• Насколько статичны данные? Если это никогда не изменится, чем жить в объекте. Чтобы изменить данные, вам, возможно, придется перекомпилировать и заново развернуть. Вы довольны передислокацией для незначительного изменения?

• Если это веб-приложение, и вы используете его как часть web.config, довольны ли вы тем, что приложение перезапускается при внесении изменений в эти данные?

• Если вы поместите его в базу данных, вы всегда можете кэшировать его на стороне клиента (настольное приложение) или на стороне сервера (сервис или веб-сайт). База данных может быть хорошим решением IMO.