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


13

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

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


2
«Однако, насколько я могу судить, я не вижу приложений (которые я использую), использующих БД очень часто»? На основании чего? Если они использовали SQLite, как вы могли бы определить, использовали ли они базу данных или нет?
С.Лотт

Вот почему я сказал, насколько я могу судить, поскольку я знал, что есть вероятность, что я ошибался. Я подумал, что могут быть некоторые приложения, использующие встроенные БД ... Часто ли приложения используют БД?
Кеннет

@ Кеннет: Пожалуйста, Google для встроенных БД, таких как SQLite. Много. Они широко используются. AFAIK, Apple, iOS использует его для всей настойчивости. Пожалуйста, Google.
S.Lott

2
Я много гуглю. Иногда, хотя ничто не заменяет опытных мнений, которые вы не всегда можете найти в Google.
Кеннет

1
Я думаю, что этих комментариев достаточно, чтобы исправить ошибочное предположение. Я прошу прощения за ошибку. Я чувствую, что использую здоровую смесь поиска в Google и вопросов. Иногда нет замены последнему ИМХО. Теперь мой поиск будет лучше направлен и продуктивен.
Кеннет

Ответы:


4

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

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


7

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

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

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


Таким образом, вы бы порекомендовали не использовать БД для автономных приложений, если только большие объемы данных не гарантируют этого?
Кеннет

Что вы думаете об использовании легких БД ... так же, как полномасштабных БД?
Кеннет

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

5

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

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


+1 Если у вас нет сложных проблем с постоянством, таких как многопользовательская, одновременная блокировка обновлений, традиционная база данных может оказаться излишней. Если рассматриваемые данные довольно статичны (они могут увеличиваться или добавляться, но не развиваться и не обновляться), а конкуренция / конкуренция не являются частыми или извращенными (побочные эффекты / опыт пользователя для ожидания освобождения блокировки) не является неприемлемым, учитывая компромиссы между производительностью и сложностью), вам может не потребоваться база данных.
JustinC

4

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

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


1
Очень похожим примером на стороне Java является Derby. Я думаю, что есть и другие.
jprete

1
Похоже, это может быть идеальным решением ... Мне действительно нравится использовать БД! лол
Кеннет

Есть ли недостатки в использовании легких БД?
Кеннет

@Kenneth: они делают вашу установку больше и могут увеличить базу кода. Но это намного меньше, чем установка целого сервера базы данных на клиенте, что обычно делается только тогда, когда приложение распространяется и требует более существенной базы данных. Berkeley DB является одним из наиболее часто используемых.
Orbling

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

2

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

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

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

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

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


1

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

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

#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»

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

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


1

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.