Каков наилучший способ определить, когда целесообразно использовать базу данных?

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

Сейчас я углубляюсь в настольные приложения, и моя естественная склонность заключается в том, чтобы снова использовать БД для хранения большого количества информации, которая будет сгенерирована при использовании приложения. Однако, насколько я могу судить, я не вижу приложений (которые я использую), использующих БД очень часто. [РЕДАКТИРОВАТЬ: С тех пор было отмечено, что это было ошибочное предположение, что многие приложения используют легкие базы данных, встроенные в саму программу.] В чем причина? В какой момент целесообразно использовать БД? Есть ли стандарты по этому вопросу? Кроме того, каковы причины НЕ использовать БД для разработки настольных приложений?

если ваше приложение ориентировано на документы, храните вещи в файле документа

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

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

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

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

Настольные приложения поддерживают состояние во время работы. В то время как веб-разработка обычно не Поэтому, хотя вам может потребоваться сохранить пользовательские настройки в базе данных между загрузками страниц, в настольном приложении вы просто сохраняете их в памяти. Это значительно уменьшает потребность в таких типах постоянного хранения. Если вы хотите сохранить настройки между использованиями, вы можете сохранить их все в один файл или поместить в другое место, например, в реестр Windows.

При этом системы баз данных довольно часто используются в настольных приложениях. Задолго до Интернета настольные приложения были подключены к СУБД. В первую очередь для приложений, которые не основаны на документах. Хотя в наши дни, благодаря лучшей доступности легких двигателей, вы видите, что линии немного размыты. Например, я использую базы данных SQLite в качестве документов в некоторых своих приложениях.

Одна вещь, которую вы, возможно, захотите рассмотреть, - это легковесные базы данных, для которых не требуется действующая служба баз данных. Например, на фронте Microsoft есть SQL Server Compact , который является бесплатным, требует только один файл для базы данных и некоторые DLL, добавленные в ваше приложение, и, с точки зрения разработчика, ведет себя почти так же, как «настоящий» SQL Server.

Я уверен, что есть подобные варианты на других платформах.

В веб-приложениях важно хранить любое постоянное состояние в централизованном хранилище. Поскольку веб-приложение обычно является первым узким местом, важно иметь возможность просто распространять его, не задаваясь вопросом, какая копия содержит данные (принцип «Shared Nothing»). По memcachedтой же причине существуют не только базы данных, но и системы очередей.

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

Приложения с графическим интерфейсом также могут иметь сложные документы, которые могут обрабатываться как сложная сеть объектов в памяти. Нормализация структуры в схему реляционной БД может значительно усложнить проблему, иногда проще просто сериализовать все в одном потоке. Многие OOP-фреймворки включают некоторые средства только для этого.

Тем не менее, сохранение хранимых документов читаемыми с помощью инструментов вне основного приложения во многих случаях является большим преимуществом, поэтому либо использование удобочитаемых форматов (XML, JSON, YAML и т. Д.), Либо объединение нескольких zip-файлов в несколько zip-файлов становятся все более и более сложными. чаще.

В том же духе, использование встраиваемой библиотеки баз данных (BDB, Tokyo Cabinet, SQLite, MS-SQL * server Compact и т. Д.) - еще один замечательный подход.

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

Например, рассмотрим:

#include "superheader.h"

int main()
{
    int row=2, column=2;
    DatabaseType db;
    db.ConnectTo("programDB", "user", "pass");
    db.setTable("messages");
    string hello_world=db.fetch(row, column);
    cout<<hello_world;
    return 0;
}

Ну, это слишком упрощенно, но, очевидно, это слишком много. Нет никакого смысла в том, чтобы иметь такой уровень управления данными для «Hello World»

Обычно я придерживаюсь практического правила: используйте базу данных, если у вас много наборов данных, особенно если они уникально отличаются, ИЛИ используйте базу данных, если объем данных довольно большой. Базы данных в целом связаны с некоторыми накладными расходами, но есть много, которые на самом деле не так много. Например, небольшие, легкие базы данных в памяти иногда полезны для небольших проектов с интенсивной обработкой, планированием или большим количеством динамических изменений данных.

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

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