Когда не следует использовать реляционную базу данных?[закрыто]

Question

Помимо сценария google/bigtable, когда не следует использовать реляционную базу данных?Почему бы и нет и что следует использовать?(вы учились «на собственном горьком опыте»?)

Answer 1

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

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

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

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

Наконец, вам просто не нужна реляционная база данных с ее полноценным языком запросов, если не ожидается непредвиденных запросов.Если нет исков с вопросами типа «сколько синих виджетов со скидкой 5% мы продали на восточном побережье, сгруппированных по продавцам?», и никогда не будет, то вы, сэр, можете жить без БД.

Answer 2

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

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

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

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

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

См. также мой другой ответ на "Базы данных нового поколения."

Answer 3

Существует три основные модели данных (C.J.Date, E.F.Codd), и я добавляю к ним плоский файл:

• плоские файлы (структура варьируется - от «глупого» плоского текста до файлов, соответствующих грамматикам, которые в сочетании с умными инструментами делают очень умные вещи, подумайте о компиляторах и о том, что они могут сделать, узкое применение при моделировании новых вещей)
• иерархический (деревья, вложенные множества – примеры:xml и другие языки разметки, реестр, организационные структуры и т. д.;смоделировать можно все, но правила целостности выразить непросто, а извлечение сложно оптимизировать автоматически, некоторый поиск выполняется быстро, а некоторые очень медленно)
• сеть (сети, графики - примеры:навигационные базы данных, гиперссылки, семантическая паутина, опять же почти все можно смоделировать, но автоматическая оптимизация поиска - проблема)
• реляционный (логика предикатов первого порядка – пример:реляционные базы данных, автоматическая оптимизация поиска)

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

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

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

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

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

Или если вас просто не особо заботит целостность ваших данных (что может быть нормально).

Все структуры данных оптимизированы для определенного типа использования, и только реляционные, если они правильно смоделированы, пытаются представить «реальность» семантически беспристрастным образом.Люди, у которых был неудачный опыт работы с реляционными базами данных, обычно не осознают, что с другими типами моделей данных их опыт был бы намного хуже.Возможны ужасные реализации, особенно с реляционными базами данных, где относительно легко строить сложные модели, и в итоге у вас может получиться настоящий монстр.Тем не менее, я всегда чувствую себя лучше, когда пытаюсь представить того же монстра в формате xml.

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

Answer 4

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

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

Answer 5

Пятнадцать лет назад я работал над системой кредитного риска (по сути, системой хождения по большому дереву).Мы использовали Sybase на HPUX и Solaris, и производительность нас убивала.Мы наняли консультантов непосредственно из Sybase, и они сказали, что это невозможно.Затем мы переключились на объектно-ориентированную базу данных (в данном случае хранилище объектов) и получили примерно 100-кратное увеличение производительности (и писать код стало примерно в 100 раз проще).

Но такие ситуации встречаются довольно редко — реляционная база данных — лучший выбор.

Answer 6

Если ваша схема сильно различается, вам будет трудно работать с реляционными базами данных.Здесь лучше всего работают базы данных XML или базы данных пар ключ-значение.или вы можете использовать IBM DB2 и иметь как реляционные данные, так и данные XML, управляемые одним механизмом базы данных.

Answer 7

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

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

Я сделал нечто подобное с сообщениями, которые пользователи отправляли друг другу.По сути, везде, где я мог заставить систему вообще обходить базу данных, избегая INSERT или UPDATE, я получал значительный прирост.Возможно, это звучит как здравый смысл, но это был поучительный момент.Это не отказ от реляционной настройки как таковой, а полный отказ от базы данных - KISS.