Хорошие причины НЕ использовать реляционную базу данных?

Question

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

Answer 1

Также: * Встроенные сценарии - где обычно требуется использовать что-то меньшее, чем полноценная СУБД. Db4o - это ODB, который может быть легко использован в таком случае. * Быстрая разработка или разработка концепции - когда вы хотите сосредоточиться на бизнесе и не беспокоиться о постоянстве

Answer 2

Полнотекстовые базы данных, к которым можно обращаться с помощью операторов близости, таких как «в пределах 10 слов» и т. Д.

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

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

Answer 3

BTree файлы часто намного быстрее, чем реляционные базы данных. SQLite содержит внутри себя библиотеку BTree, которая находится в общественном достоянии (как в подлинно «общественном достоянии», не употребляя термин свободно).

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

Answer 4

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

Answer 5

K.I.S.S: пусть он будет маленьким и простым

Answer 6

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

Мы часто используем XML-файлы - вы получаете хорошо структурированные данные, хорошие инструменты для запроса, возможность вносить изменения, если это уместно, что-то удобочитаемое для человека, и вам не нужно беспокоиться о работе механизма БД (или работы двигателя дб). Это хорошо работает для вещей, которые по сути только для чтения (в нашем случае чаще, чем не сгенерированные из БД в другом месте), а также для однопользовательских систем, где вы можете просто загрузить данные и сохранить их по мере необходимости - но вы создаете возможности для проблем, если вы хотите многопользовательское редактирование - хотя бы одного файла.

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

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

Murph

Answer 7

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

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

Такие сервисы, как Amazon S3 , предоставляют более простые модели хранения (ключ-> значение), которые не поддерживают SQL. Масштабируемость - вот ключ.

Файлы Excel также могут быть полезны, особенно если пользователи должны иметь возможность манипулировать данными в знакомой среде и создать полноценное приложение, чтобы сделать это невозможно.

Answer 8

Я бы предложил RDBMS :) Если у вас нет проблем с настройкой / администрированием, перейдите на SQLite. Встроенная СУБД с полной поддержкой SQL. Он даже позволяет хранить данные любого типа в любом столбце.

Главное преимущество по сравнению, например, с лог-файлом: если у вас огромный файл, как вы собираетесь его искать? С помощью механизма SQL вы просто создаете индекс и значительно ускоряете работу.

О полнотекстовом поиске: в SQLite есть модули для полнотекстового поиска.

Просто наслаждайтесь красивым стандартным интерфейсом для ваших данных:)

Answer 9

Теорема CAP объясняет это кратко. SQL в основном обеспечивает «строгую согласованность: все клиенты видят одно и то же представление даже при наличии обновлений».

Answer 10

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

В Hadoop также реализована Файловая система Google , называемая Распределенная файловая система Hadoop .

.