Хранить статические данные в массиве или в базе данных?

У нас всегда есть статические данные, которые могут быть сохранены в файле в виде массива или сохранены в таблице базы данных в нашем веб-проекте. Итак, какой из них предпочтительнее?

На мой взгляд, массивы имеют некоторые преимущества:

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

Но мой коллега утверждал, что он предпочитает подход БД, поскольку он может поддерживать единый интерфейс сохранения данных и быть более гибким.

Итак, что должно быть предпочтительнее? Или как мы можем выбрать? Или мы должны предпочесть один в каком-то сценарии, а другой - в других сценариях? каковы сценарии?

EDIT:

Позвольте мне кое-что уточнить. Поистине точно так же, как Бенджамин внес изменения в заголовок, данные, которые мы хотим сохранить в массиве (файле), не будут меняться так часто, а это значит, что код не изменит значение массива во время выполнения. Если данные будут меняться очень часто, я буду использовать DB без сомнения. Вот почему я сделал такую ​​запись.

И иногда трудно хранить некоторые очень сложные отношения, например:

Task = {
 "1" : {
 "name" : "xx",
 "requirement" : {
 "level" : 5,
 "money" : 100,
 }
 ...
 }

Как и предыдущий пример кода (python dict или вы можете считать его как массив), поле требований трудно сохранить в БД (хранить структуру, подобную маринованному объекту непосредственно в БД, не так хорошо, как мне кажется). Поэтому в таком состоянии я предпочитаю массивы.

Итак, что вы думаете? В таком сценарии мы должны предпочесть массивы DB, правильно?

С уважением.

6 ответов

Позволяет быть прагматичным/объективным:

  • Вы записываете свои данные во время выполнения? Да: Db, Нет: Файл
  • Вы обновляете свои данные более одного раза в неделю? Да: Db, Нет: Файл
  • Вам больно выпускать обновленный файл данных? Да: Db, No: File,
  • Вы часто читаете эти данные? Да: Файл/Кэш, Нет: Db
  • Вам больно обновлять этот файл данных и вам нужны дополнительные инструменты? Да: db, Нет: Файл

Конечно, я забыл другие моменты, но я думаю, что здесь есть основы.


"Гибкий" массив в файле чреват большим количеством проблем, связанных с использованием DB. Если вы не сможете доказать, что БД действительно идет медленнее, чем использовать другой подход, используйте БД. Переходите и начинайте решать бизнес-задачи.

Edit

Комментарий от OP спрашивает, какие могут быть проблемы с использованием файла, вот несколько (пауза, чтобы сделать глубокий вдох).

  • Concurrency: вам нужно управлять ситуацией, когда несколько запросов могут пытаться записать обратно в файл. Не слишком сложно, но это становится узким местом.
  • Производительность. Да, изменение массива в памяти происходит быстрее, но как вы определяете, сколько и когда массив должен сохраняться в файле. Обратите внимание, что использование БД не требует предварительного использования соответствующего кэша в памяти. Запись файла обратно каждый раз, когда выполняется небольшая модификация, не будет хорошо работать.
  • Масштабируемость: действительно функция первых двух. Чтобы достичь любых масштабируемых целей, вам нужно иметь возможность быстро модифицировать небольшие биты данных, которые сохраняются. IWO, если вы не используете БД, вы в итоге пишете ее. Если вы обнаружите, что вам нужен более одного веб-сервера для поддержки растущего спроса, где вы собираетесь хранить файл (ы)? Теперь у вас есть файловый ввод-вывод по сети (возможно, очень быстрый).
  • Структура. Ваш код будет отвечать за управление структурой данных, запросами и т.д., если вы используете массив. Как вы это сделаете так, чтобы добиться большей "гибкости", чем при использовании БД? Здесь нужны всевозможные варианты и сложность.
  • Надежность. Вам необходимо обеспечить целостность ваших сохраненных данных. В случае некоторого сбоя ваш код массива/файла должен будет гарантировать, что данные по крайней мере не настолько повреждены, что приложение может продолжить.


Ваш коллега прав, но там, где вам нужно отложить учебник comp sci и быть прагматичным. Как часто вы будете получать доступ к этим данным из своего приложения? Если это довольно часто, то не нести расходы на накладные расходы. Вместо чтения из плоского файла вы все равно можете получить преимущества db, но используйте стратегию кэширования в своем приложении. В зависимости от языка разработки вы можете посмотреть что-то вроде memcache или jtreecache.


Да, я согласен с вашей подразумеваемой оценкой того, что базы данных чрезмерно используются, а базовые плоские файлы могут работать во множестве сценариев. Если ваше приложение доступно только для чтения (и записи выполняются администратором при перезагрузке приложения), я бы определенно пошел с файлом. Даже если приложение записывает в файл, но только в режиме добавления (vs random inserts/updates) в одном потоке, я бы также использовал файл. Все остальное - нужна настоящая база данных со случайными обновлениями, запросами, concurrency и т.д.


Если данные не сильно меняются, а ваше программирование на Java, почему бы не использовать Spring для хранения значений?

Они могут быть введены в ваш bean и легко изменены.

но это если вы развиваетесь на Java.


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

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

licensed under cc by-sa 3.0 with attribution.