В какой момент стоит использовать базу данных? - PullRequest
52 голосов
/ 16 апреля 2010

У меня есть вопрос, касающийся баз данных и в какой момент стоит погрузиться в одну. Я прежде всего инженер по встраиванию, но я пишу приложение, использующее Qt для взаимодействия с нашим контроллером.

Мы находимся в странном положении, когда у нас достаточно данных, чтобы можно было реализовать базу данных (более 700 и более элементов и увеличивать ее), чтобы управлять всем, но я не уверен, что сейчас стоит потратить время на решение этой проблемы. , У меня нет проблем с реализацией графического интерфейса с файлами, сгенерированными из Excel и проанализированными, но его становится утомительно и сложно отследить даже с помощью сценариев VBA. Я занимался преобразованием наших данных в нечто более управляемое для приложений с помощью Microsoft Access, и это, похоже, работает хорошо. Если это сработает, я только на шаг (или несколько) от использования базы данных SQL и использования библиотеки Qt для доступа к ней и ее изменения.

У меня нет большого опыта в управлении данными на этом уровне, и мне интересно, что может быть лучшим способом приблизиться к этому. Итак, каковы реальные преимущества использования базы данных, если таковые имеются в этом случае? Я понимаю, что многое из этого может зависеть от конкретного приложения, но некоторые общие идеи и предложения о том, как расположить линию встроенного / прикладного программирования, были бы полезны.

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


Я решил пойти с SQLite. Вы можете сделать некоторые очень интересные вещи с данными, которые я действительно не рассматривал как вариант при первом запуске этого проекта.

Ответы [ 13 ]

38 голосов
/ 16 апреля 2010

База данных стоит, когда:

  1. Ваше приложение развивается до некоторых форма выполнения данных.
  2. Вы тратите время на разработку и разработка внешнего хранилища данных структур.
  3. Обмен данными между приложениями или организации (в том числе индивидуальные человек)
  4. Данные больше не короткие и простой.
  5. Дублирование данных

Эволюция в исполнение, управляемое данными
Когда данные изменяются, а выполнение не изменяется, это признак программы, управляемой данными, или части программы, управляемые данными. Набор параметров конфигурации является признаком управляемой данными функции, но все приложение может не быть управляемым данными. В любом случае база данных может помочь управлять данными. (Библиотека базы данных или приложение не обязательно должны быть огромными, как Oracle, но могут быть простыми и иметь в виду, как SQLite).

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

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

Комплексные данные
Программы начинаются с использования небольших таблиц с жестко закодированными данными. Это превращается в использование динамических данных с картами, деревьями и списками. Иногда данные расширяются от двух простых столбцов до 8 и более. Теория баз данных и базы данных могут облегчить сложность организации данных. Позвольте базе данных беспокоиться об управлении данными и освободите ваше приложение и ваше время разработки. В конце концов, управление данными не так важно, как качество данных и их доступность.

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

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

8 голосов
/ 16 апреля 2010

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

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

Я бы сказал, что примерно в 90% случаев в этом масштабе вы будете пользоваться облегченной базой данных, такой как SQLite, при условии, что:

  1. Данные могут потенциально значительно увеличиться по сравнению с тем, что вы описываете,
  2. Данные могут совместно использоваться более чем одним пользователем,
  3. Вам может потребоваться выполнить запросы к данным (что я не думаю, что вы делаете сейчас), и
  4. Данные можно легко описать в виде таблицы.

В остальные 10% времени ваши данные будут высоко структурированными, иерархическими, основанными на объектах и ​​не будут точно вписываться в табличную модель базы данных или таблицу Excel. Если это так, рассмотрите возможность использования файлов XML.

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

Синтаксические анализаторы XML и связыватели данных для C ++ легко найти .

4 голосов
/ 16 апреля 2010

Я рекомендую вам ввести базу данных в ваше приложение, ваше приложение приобретет гибкость, его будет проще поддерживать и улучшать с помощью новых функций в будущем.
Я бы начал с легкого файла на основе базы данных, как Sqlite .
С хорошо разработанной БД у вас будет:

  1. Уменьшенная избыточность данных
  2. Большая целостность данных
  3. Улучшенная защита данных

И последнее, но не менее важное: использование базы данных избавит вас от ада Excel / import / update / export !

3 голосов
/ 16 апреля 2010

Причины использования базы данных:

  • Параллельная запись. Достигнуть параллелизма в базах данных легко
  • Легкий запрос. SQL-запросы, как правило, гораздо лаконичнее процедурного кода для поиска данных. ОБНОВЛЕНИЯ, INSERT INTO могут также делать много вещей с очень небольшим кодом
  • Integrity. Ограничения очень легко определить и применяются без написания кода. Если у вас есть ненулевое ограничение, вы можете быть уверены, что значение не будет нулевым, не нужно нигде писать чеки. Если у вас есть ограничение внешнего ключа, у вас не будет «свисающих ссылок».
  • Производительность на больших наборах данных. Индексирование очень просто добавить в базу данных SQL

Причины, по которым база данных не используется:

  • Это, как правило, дополнительная зависимость (хотя существуют очень легкие базы данных - например, мне нравится H2 для Java)
  • Данные не очень подходят для реляционной схемы. Вещи, которые в основном являются картами ключ / значение. XML (хотя базы данных часто поддерживают XPath и т. Д.).
  • Иногда файлы удобнее. Их можно анализировать, объединять, редактировать в текстовом редакторе и т. Д. Иногда электронные таблицы могут быть более практичными (вам не нужно создавать редактор - вы можете использовать программу для работы с электронными таблицами)
  • Ваши данные уже где-то еще
2 голосов
/ 17 апреля 2010

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

  • Увеличивается ли объем данных, которые приложение использует / создает?
  • Является ли верхний предел роста этих данных неизвестным (или неясным)?
  • Нужно ли приложению собирать или фильтровать эти данные?
  • Могут ли в будущем использоваться данные, которые сейчас могут быть неочевидны?
  • Важна ли производительность поиска и / или хранения данных?
  • Существует ли (или может быть) несколько пользователей приложения, которые обмениваются данными?

Если я отвечаю «Да» на большинство из этих вопросов, я почти всегда выбираю базу данных (в отличие от других опций, таких как XML / ini / CSV / Excel / текстовые файлы или файловая система).

Кроме того, если в приложении будет много пользователей, которые могут одновременно получать доступ к данным, я буду склоняться к полному серверу баз данных (MySQL, SQl Server, Oracle и т. Д.).

Но часто в ситуации с одним пользователем (или небольшим параллелизмом) локальную базу данных, такую ​​как SQLite, нельзя превзойти по переносимости и простоте развертывания.

2 голосов
/ 16 апреля 2010

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

  • количество записей
  • размер элементов данных
  • нужна ли база данных для других устройств? Одновременно с этим?
  • насколько сложны отношения между различными частями данных
  • база данных доступна только для чтения (например, создана во время сборки и не изменена)?
  • нужно ли обновлять базу данных несколькими сущностями одновременно?
  • вам нужно поддерживать сложные запросы?

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

2 голосов
/ 16 апреля 2010

Я вижу довольно много требований, которым хорошо отвечают базы данных:

1). Специальные запросы. Найдите мне все {X}, которые соответствуют критериям Y

2). Данные со структурой, которые могут извлечь выгоду из нормализации - разложить общие значения в отдельные «таблицы». Таким образом, вы можете сэкономить место и уменьшить вероятность несоответствия. Как только вы это сделаете, эти специальные запросы станут действительно полезными.

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

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

2 голосов
/ 16 апреля 2010

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

Например, вы можете добавить базу данных SQLite во встроенное приложение, которое должно регистрировать статистику, и вы не знаете, как ее использовать. Позже вы отправляете полную базу данных для внедрения в большую базу данных, работающую на центральном сервере, и эти данные можно легко использовать, используя запросы.

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

1 голос
/ 16 апреля 2010

Мы также сталкиваемся с подобной ситуацией. У нас есть набор данных, поступающих из разных тестовых установок, и в настоящее время они выгружаются в таблицы Excel, обработанные с использованием Perl или VBA.

Мы обнаружили, что у этого метода было много проблем:

я. Управление данными с использованием таблиц Excel довольно громоздко. Через некоторое время у вас появилось много листов Excel, и не было простого способа извлечь из него необходимые данные.

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

III. Создается несколько копий файлов, а изменения в одной копии не отражаются в другой - управление версиями отсутствует.

Это по тем же причинам, по которым мы решили перейти к решению на основе базы данных и в настоящее время работаем над этим. Позвольте мне кратко изложить, что мы пытаемся сделать:

я. База данных находится на центральном сервере, доступном для ПК во всех тестовых установках.

II. Все данные попадают во временное местоположение (локальный жесткий диск в файлах), как только они генерируются. Из файлов он помещается в базу данных процессом, работающим в фоновом режиме (поэтому, даже если возникает проблема с сетью, данные будут присутствовать в локальной файловой системе).

III. У нас есть веб-приложение, которое позволяет пользователям входить в систему и получать доступ к данным в нужном им формате. Портал позволит им добавлять комментарии, создавать отчеты различного типа, делиться ими с другими пользователями после просмотра и т. Д. Он также будет иметь возможность экспортировать данные в таблицу Excel на случай, если вам понадобится взять их с собой.

Дайте понять, может ли это быть лучше реализовано.

1 голос
/ 16 апреля 2010

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

Как таковое использование базы данных гораздо более осуществимо. Использование одного из них на встроенной платформе является гораздо более сложной проблемой.

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...