Базы данных против простого текста

Question

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

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

Answer 1

1) Параллелизм. У вас есть несколько человек, которые имеют доступ к одному и тому же набору данных? Затем, когда вы развернете свою собственную систему, вы будете вовлечены в процесс брокерства всех читателей и писателей в масштабируемом режиме .

2) Форматирование и отношения. Являются ли ваши данные чем-то, что не вписывается в структуру таблицы? Длинные нуклеотидные последовательности и тому подобное? Это не очень удобно для табличных данных.

Другой пример. Никто не подумал бы о реализации программного обеспечения, такого как Photoshop, для хранения PSD в реляционном формате, потому что структуры данных на самом деле не подходят для такого типа хранилища или шаблона запроса.

3) КИСЛОТА (своего рода следствие # 1): если атомарность, согласованность, целостность и долговечность не являются проблемами с плоским файлом, то используйте плоский файл.

Answer 2

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

• SQLite (Отлично, почти соответствует стандарту SQL-92)
• shsql
• SQL Server Compact

Answer 3

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

Answer 4

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

Для реляционных данных я бы использовал SQLite. Для пар ключ / значение я бы использовал BerkeleyDB (возможно, через KiokuDB). Для простых объектов я бы использовал JSON или YAML, но только если бы у меня их было несколько.

В SQLite и BDB «настоящая база данных» буквально в двух строках кода. Это трудно победить.

Answer 5

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

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

Answer 6

Это полностью зависит от потребностей приложения. Часто прямой доступ к текстовым файлам / двоичным файлам может быть чрезвычайно быстрым, эффективным, а также предоставляет вам все возможности доступа к файлам файловой системы вашей ОС.

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

Если вам нужно много добавлений (INSERTS?) И последовательный / мало доступа / мало параллелизма, файлы - это путь.

С другой стороны, когда ваши требования к параллелизму, непоследовательному чтению / записи, атомарности, атомарным разрешениям, вашим данным носят реляционный характер и т. Д., Вам будет лучше с реляционной или OO базой данных.

Многое можно сделать с помощью SQLite3 , который является чрезвычайно легким (до 300 КБ), совместимым с ACID, написанным на C / C ++, и вездесущим (если он еще не включен в Ваш язык программирования, например, Python, наверняка есть. Это может быть полезно даже для файлов размером 1 ГБ, возможно больше.

Если ваши требования куда больше, даже обсуждения не будет, перейдите на полноценную СУБД.

Answer 7

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

Вы, вероятно, будете запрашивать некоторые веб-сервисы, файлы или базы данных, запускать локальные алгоритмы для данных, собранных из разных источников, и создавать какой-либо табличный или структурированный формат вывода (xml, json и т. Д.).

Для этого я бы предложил вам использовать инструменты рабочего процесса, такие как Knime (или коммерческое решение, такое как Inforsense KDE , Accelrys's Pipeline pilot или Snaplogic , поскольку они позволяют запрашивать данные в различных форматах и ​​местах (rdbms, плоские файлы, веб-сервисы), запускать алгоритмы и создавать мощные веб-приложения, которые позволяют легко публиковать рабочие процессы для ваших пользователей и позволяют они взаимодействуют в определенных точках).

Если ваш прототип «растет», и вам необходимо создать больше функциональности поверх данных, выводимых вашими рабочими процессами, и если выходные данные вашего прототипа вряд ли будут меняться каждый день, то разумным решением будет сохранить подмножество результаты в базе данных. Это позволяет вам подключать мощные инструменты отчетности, такие как BusinessObjects, отчеты Crystal, отчеты Jasper или любое другое решение для создания отчетов, и показывать данные пользователям в лучшей форме, чем электронная таблица или файл CSV.

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

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

Answer 8

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

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

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

Answer 9

Во-первых, я бы рассмотрел:

1. Насколько большой будет первоначально база данных: # таблиц, # строк
2. Как быстро он будет расти?
3. Часто ли запрашиваются данные?

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

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

Answer 10

Вам нужны / нужны запросы SQL?

Несколько человек захотят получить доступ к данным?

Являются ли ваши данные реляционными?

Если вы ответили «нет» на эти вопросы, вам (вероятно) не нужна полная база данных.