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

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

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

Ответ 1

1) Concurrency. У вас есть несколько человек, которые обращаются к одному набору данных? Тогда он будет очень привлекательным, чтобы бронировать всех разных читателей и писателей масштабируемым образом, если вы катите свою собственную систему.

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

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

3) ACID (что-то вроде следствия к № 1): если Atomity, Consistency, Integrity и Durability не являются проблемами с плоским файлом, перейдите к плоскому файлу.

Ответ 2

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

SQLite (отлично, почти стандартный SQL-92)
shsql
SQL Server Compact

Ответ 3

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

Ответ 4

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

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

С SQLite и BDB "реальная база данных" буквально находится в двух строках кода. Трудно это победить.

Ответ 5

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

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

Ответ 6

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

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

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

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

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

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

Ответ 7

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

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

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

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

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

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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

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

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

Ответ 11

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

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

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

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

Ответ 12

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

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

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

Ответ 13

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

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

Для многих (большинства?) нас наша зона комфорта для сохранения данных - это SQL. Для некоторых это может быть XML. Просто не пишите свой собственный, пока (см. Параграф 2).

Ответ 14

Как и кто-то, кто занимается исследованиями в области биоинформатики, я бы предложил НЕ использовать базу данных для таких проектов прототипов, если вы не уверены, что это необходимо. Если вы находитесь на заборе, пойдите с безрезультатным решением и придерживайтесь плоских файлов. Также важно отметить, что традиционно исследователи Bioinformatics идут по плоскому файловому маршруту, что означает, что для большинства типов данных в feild имеются хорошо определенные форматы файлов. Если вы решите пойти с решением для базы данных, это может повредить вашей совместимости с существующими исследовательскими проектами.