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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

но такие ситуации довольно редки-реляционная база данных является хорошим первым выбор.

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

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

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

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