Веб-разработка - Object db vs Relational db
Каковы преимущества и недостатки использования объектной базы данных или реляционной базы данных для обычной веб-разработки, которая включает в себя много CRUD?
ОБНОВЛЕНИЕ: я вновь открыл награду за вознаграждение, чтобы дать Невиллу это.
8 ответов
Реляционная база данных:
Плюсы:
- Отработанные технологии - множество инструментов, разработчиков, ресурсов
- Широкий ассортимент Open Source и коммерческих продуктов
- Известно, что масштабируется для очень больших сайтов и очень высокой пропускной способности
- Выражает много проблемных областей в логическом и "программируемом" виде
- Довольно стандартный язык (SQL)
Минусы:
- Несоответствие импеданса понятиям ОО - моделирование "наследования" в базе данных не является естественным
- Иерархические структуры обычно требуют специфических расширений языка
- Нереляционные данные (например, документы) не являются естественным соответствием
- Изменения в бизнес-сфере могут быть трудноосуществимыми после определения схемы
OOBDMS
Плюсы:
- Ближе подходит для концепций ОО
- Теоретически, разработчик должен работать только на одном языке - детали персистентности абстрагируются. Это должно улучшить производительность
Минусы:
- Значительно меньше инструментов / ресурсов / разработчиков доступно.
- Нет общепринятых стандартов
- Подход "черного ящика" к постоянству может затруднить настройку производительности
- детали персистентности часто просачиваются в дизайн ОО (см. примеры Марсело)
Концепция OODBMS довольно разрушена, и различные коммерческие и бесплатные предложения, появившиеся за последние несколько десятилетий, едва заметили на рынке.
Реляционная модель является более мощной, чем объектные модели, с точки зрения видов вопросов, которые вы можете задать своим данным. К сожалению, SQL отбросил большую часть выразительных возможностей, на которые способна реляционная модель, но даже в этой разбавленной форме все еще проще выражать запросы в SQL, чем в обычной базе данных OO (будь то ORM или OODBMS).
Запросы в OODBMS в основном выполняются навигационными операторами, а это означает, что если в вашей базе данных по продажам есть продавцы, владеющие своими продажами, то запросы о ежемесячных продажах для определенного SKU будут не только крайне медленными, но и очень неудобными для выражения. Рассмотрим также модель безопасности, которая предоставляет сотрудникам доступ к зданиям. Какой правильный способ выразить это? Должны ли сотрудники иметь набор зданий, к которым они имеют доступ, или здания должны содержать набор сотрудников, которые имеют к ним доступ? Более того, почему один класс должен иметь коллекцию другого, включенную в его дизайн? И какой бы вы ни выбрали, как бы вы спросили, какие пары сотрудников имеют более одного здания, к которому они могут получить доступ совместно? Не существует простой навигационной схемы, которая могла бы ответить на такой вопрос. Разумное решение - объект "Доступ" - это, по сути, возврат к правильно нормированной реляционной схеме, и для этого требуется некоторый язык запросов, который в значительной степени заимствует из реляционной алгебры, чтобы ответить на вопрос без значительных перерасходов. проводная передача данных.
Также рассмотрим еще одну важную силу, о которой говорят в OODBMS: методы, особенно наследование виртуальными методами. Спортивная клиника может иметь разные показатели риска получения травмы для разных видов спортсменов. В мире ORM это будет автоматически выражаться в виде иерархии классов с Athlete в корне, и виртуальный метод, int InjuryRiskScore() реализуется каждым производным классом. Проблема заключается в том, что этот метод неизменно реализуется на клиенте, а не на бэкэнде, поэтому, если вы хотите найти 10 спортсменов с самым высоким риском во всех видах спорта в вашей клинике, единственный способ сделать это - собрать всех спортсменов через провод и передать их через очередь приоритетов на стороне клиента. Я также не знаю мир OODBMS, но я думаю, что та же проблема возникает, так как механизмы хранения обычно хранят только достаточно данных для регидратации объектов на языке программирования клиента. В реляционной модели или SQL вы можете выразить оценку риска травмы как представление, которое может быть просто объединением представлений для каждого спортсмена. Тогда вы просто задаете вопрос. Или вы можете задать более сложные вопросы, такие как: "У кого был самый большой рост риска травм со времени проверки в прошлом месяце?" или даже "Какой показатель риска оказался лучшим предиктором травмы за последний год?". Самое главное, что на все эти вопросы можно получить ответы внутри СУБД, причем не более, чем вопрос и ответ, передаваемые по проводам.
Реляционная модель позволяет СУБД выражать знания с высокой степенью детализации на основе логики предикатов, которая позволяет объединять, прогнозировать, фильтровать, группировать, суммировать и иным образом преобразовывать различные измерения фактов, которые вы в них храните, в совершенно произвольную форму. манера. Это позволяет вам легко составлять данные способами, которые не предполагались при первоначальном проектировании системы. Таким образом, реляционная модель допускает самое чистое выражение знаний, которое мы знаем. Короче говоря, реляционная модель содержит чистые факты - ни больше, ни меньше (и, конечно, не объекты или их прокси).
На историческом примечании реляционная модель возникла в ответ на катастрофическое положение дел с существующими сетевыми и иерархическими СУБД того времени и в значительной степени (и справедливо) вытеснила их для всех, кроме небольшой ниши областей применения (и даже этих, вероятно, остались в основном из-за того, что SQL не смог обеспечить питание RM). Глубоко иронично то, что большая часть индустрии сейчас тоскует по "старым добрым временам" теоретических сетевых баз данных, а это, по сути, то, к чему стремятся OODBMS и текущий набор баз данных NoSQL. Эти усилия справедливо критикуют SQL за его неспособность удовлетворить сегодняшние потребности, но, к сожалению, они предположили (ошибочно и, вероятно, из-за чистого невежества), что SQL является высокоточным выражением реляционной модели. Следовательно, они пренебрегали даже рассмотрением самой реляционной модели, которая практически не имеет ограничений, которые уводят многих от SQL, часто к OODBMS.
Я могу ответить на ваш вопрос относительно одной базы данных объектов, которую я хорошо знаю: ZODB.
ZODB позволяет вам сохранять свои модели данных почти полностью прозрачно. Его использование составляет что-то вроде:
# 'Persistent' allows us to save things transparently
class Car(Persistent):
def set_wheels(number)
self.wheels = number
# 'database' is a ZODB database
database.car = Car()
database.car.set_wheels(3)
Вам придется долго смотреть, чтобы найти такую читабельность с помощью RDMBS. Что есть большой плюс в использовании ZODB в веб-приложении.
Большим недостатком, как подчеркивает Марчелло, является отсутствие мощных запросов. Это отчасти побочный эффект удобства идиомы выше. Следующее полностью нормально, и все будет сохранено в базе данных:
database.car.colour = "yellow"
database.car.owner = "Trotter"
database.car.neighbour = Car()
Однако такая гибкость затрудняет оптимизацию сложных запросов для разных моделей. Просто составление списка всех желтых автомобилей с соседями потребует O(n) время, если вы не катите свой собственный индекс.
Таким образом, это зависит от того, что вы подразумеваете под "обычной веб-разработкой". Многие веб-сайты на самом деле не требуют сложных многомерных запросов, и поиск за линейное время не представляет никакой проблемы. В этих случаях использование СУБД может, по моему мнению, усложнить ваш код. Я написал много приложений типа CMS, использующих исключительно объектную базу данных. Много CRUD не особенно вступает в это; ZODB очень зрелый, хорошо масштабируется и кэшируется.
Однако, если вы пишете веб-приложение, которое должно составлять сложные бизнес-отчеты по аналогии с Google Analytics, или какую-то систему управления складскими запасами со многими терабайтами данных, то вам определенно понадобится СУБД.
Подводя итог, можно сказать, что объектная база данных может обеспечить удобочитаемость и удобство обслуживания за счет производительности сложных запросов. Конечно, читабельность - это вопрос мнения, и вы не можете игнорировать тот факт, что гораздо больше разработчиков знают SQL, чем различные диалекты объектной базы данных.
В обычной веб-разработке я использую Seaside на Gemstone. Для большинства приложений это означает, что я пишу нулевой код подключения к базе данных. Он работает, масштабируется, разработка идет в пять раз быстрее.
Единственный раз, когда я снова буду использовать реляционную базу данных для веб-разработки, это когда мне нужно подключиться к существующей.
Преимущества:
- меньше кода, более быстрая разработка;
- гораздо лучшая масштабируемость;
- может обрабатывать гораздо более сложные модели;
- намного лучшая ловкость проекта;
- я упомянул гибкость;
- может обрабатывать изменения в моделях классов, не только данных, но и кода;
Недостатки:
- вам, вероятно, придется самостоятельно обучать разработчиков;
- тот, который вы хотите (драгоценный камень) стоит больших денег для больших систем
Реляционная дБ
- SQL и стандарты
- легко моделировать
- можно использовать только стандартные и типы поставщиков
- ссылочная целостность (математически солидная теория реляционных множеств)
- много инструментов и реализации баз данных
- данные отдельно от программы
- управление хранением и поддержка инфраструктуры высокого уровня
- управление транзакциями и параллелизмом
- Реляционная модель основана на значениях, т.е. строки идентифицируются первичными ключами.
Cons
- нет пользовательского типа
- нет расширяемых типов данных
- Несоответствие импеданса
- не может выразить вложенные отношения
- не может использовать сложные объекты как единое целое
- необходимо определить ключи и различные типы отношений на уровне модели данных
- написать процедуры для управления версиями, транзакции при необходимости
БД объекта
- Высокая производительность
- Быстрее, так как не требуется никаких соединений
- Механизм управления версиями
- Навигационный интерфейс для операций (например, обход графика)
- Object Query Language извлекает объекты декларативно
- сложные типы данных
- идентичность объекта т.е. equals(), в котором идентичность объекта не зависит от значения и обновлений
- облегчает совместное использование объекта
- классы и иерархии (наследование и инкапсуляция)
- поддержка отношений
- интегрирован с постоянным языком, таким как ODL
- поддержка атомарности
- поддержка вложенных отношений
- семантическое моделирование
Cons
- Нет математического обоснования, как RDB (см. Кодд)
- минусы ориентации объекта
- сложность сложных структур, некоторые данные должны быть временными
Объектно-реляционные базы данных (возможно, вы видели UDT!)
- поддержка сложных типов данных, таких как сбор, мультимножества и т. д.
- объектно-ориентированное моделирование данных
- расширенный SQL и расширенные типы
- поддержка наследования UDT
- мощный язык запросов
Различные подходы (OO, Relational DB или OODB) могут быть необходимы для разных приложений
Рекомендации
Преимущество использования реляционных баз данных для крупных корпораций
Реляционная база данных Реляционная база данных
Преимущества реляционной базы данных
Манифест об объектно-ориентированной базе данных
Объектно-ориентированные базы данных
Объектные реляционные базы данных в СУБД
Критерии полноты для объектно-реляционных систем баз данных
Сравнения
http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
http://en.wikipedia.org/wiki/Comparison_of_object_database_management_systems
http://en.wikipedia.org/wiki/Comparison_of_object-relational_database_management_systems
Я думаю, что все зависит от специфики вашего вопроса. (Я действительно иду на конечности здесь, я знаю.)
Все, что мы знаем, это то, что вы хотите использовать БД для веб-разработки, и вы будете выполнять множество операций с данными.
Один из важных вопросов, который следует задать себе: насколько важно, чтобы БД была тесно интегрирована с объектами, которыми вы управляете? Чем больше это необходимо, тем больше объектно-ориентированная БД рекомендует себя.
С другой стороны, если ваши данные легко поддаются реляционной модели, реляционная БД может быть лучше.
Подумайте об операциях, которые вам нужно сделать. Вам понадобится анализ всех видов предметов с разными атрибутами? Сколько вам понадобится, чтобы обеспечить безопасность вашей базы данных в будущем?
Я должен добавить, что если ваша БД, вероятно, будет довольно маленькой, производительность не будет главной проблемой. Но если производительность, на самом деле, является проблемой, у вас есть много поводов для беспокойства, помимо ОО или реляционных БД. (Просто чтобы выбрать один пример из мира реляционных БД, какую форму нормализации следует использовать? Это чрезвычайно важный и сложный вопрос. Поддерживаете ли вы операционную систему или хранилище данных? Знаете ли вы заранее, что определенные запросы первостепенной важности или незначительной важности? &c.)
Помимо вопроса о производительности БД и интеграции с вашей объектной моделью, существуют и другие реальные вопросы. Есть ли у вас ограничения дискового пространства / сервера / пропускной способности? Будете ли вы предлагать веб-пользователям только небольшое количество операций, или люди, которых вы даже не знаете, будут создавать свои собственные запросы / правки?
Для других, более важных, реальных вопросов, с кем вы будете работать? Что они уже знают (или предпочитают)? И если у вас еще нет знаний в предметной области, может быть, у вас есть личное любопытство, подталкивающее вас в одном направлении? Если вы начинаете личный проект, следуйте собственным предпочтениям - это лучшее руководство к успеху, чем беспокойство по поводу производительности еще до того, как вы начнете.
Если вы сможете ответить на эти и подобные вопросы, даже если ответ "Я не знаю", вы сможете получить гораздо лучшее направление в том, как действовать дальше.
В контракте с подробным и хорошо продуманным ответом Марсело я бы сказал, что, исходя из формулировки вашего вопроса "регулярная веб-разработка", я бы сказал, что вам будет сложно найти достаточно профессионалов. оправдать использование объектной БД поверх традиционной реляционной базы данных, для простого факта, что больше ресурсов / разработчиков / учебных пособий / и т. д., которые более знакомы с традиционной реляционной моделью, и как использовать это для достижения "обычной веб-разработки".
Тем не менее, я думаю, что с некоторыми из современных ORM вы получаете немного лучшего из обоих миров, поскольку ваши базовые данные хранятся в хорошо понятной СУБД (которая, вероятно, стабильна, поддерживается и т. Д.), Но вы можете по-прежнему абстрагируемся от некоторых возможностей объектного моделирования, которые (возможно) могут быть более подходящими для разработки приложений CRUD.
Я признаю, что я не очень хорошо разбираюсь в текущих возможностях современных OODBMS, однако, если вы не находитесь в области, которая полностью подходит для достижения идеального объектного представления вашего домена (и у вас есть талант объектного моделирования, чтобы воспользоваться), то я бы остановился на RDBMS для вашего постоянного хранилища.
Надеюсь, это поможет!
Это в значительной степени объясняет плюсы и минусы: