О ужах и о ежах СУБД (преамбула блога).

добавлено: 02 апр 13
понравилось:0
просмотров: 1725
комментов: 0

теги:

Автор: U-gene

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

Аналогия с ужами и ежами, без сомнения, справедлива для существующих ОО языков и систем программирования с одной стороны, и существующих РСУБД, с другой. Замечу, что это существенная и дорогая проблема – по мнению Мартина Фаулера (и многих его коллег), высказанному в книге "Архитектура корпоративных программных приложений", затраты на организацию обмена данными между ОО программой и реляционной БД составляют в среднем треть стоимости проектов.

Типичность заключается в том, что авторы многих подобных статей от частных проблем, как правило, переходят к обобщению, согласно которому причина этих трудностей носит принципиальный характер. Существует практически общепринятое мнение, что де объекты и таблицы вместе не уживаются, и между ними имеются фундаментальные и, поэтому, непреодолимые противоречия. Причиной невозможности предложить общее решения называют и отсутствие в ООП "формальной теоретической базы". Используют даже специальный термин "object-relational impedance mismatch" (по-русски, "потеря соответствия"). Кажется, эти "фундаментальная несовместимость и потеря соответствия" уже введены в некоторые ВУЗовские курсы.

Какого-либо внятного объяснения, в чем заключается "фундаментальность" этой "потери соответствия", мне так и не удалось найти. Все говорят о его проявлениях. Сам термин "impedance mismatch" появился аж в 1984 году, но его авторы вкладывали в него гораздо более практический смысл. В 90-х годах тема "объекты и таблицы" была в большой моде и, в результате, на свет явились Объектно-Реляционные СУБД. Мода прошла (точнее сменился новыми модными темами), и выяснилось, что красивая приставка "Объектно-" к знакомым буквам РСУБД вовсе не является синонимом ОО в традиционном понимании. Если кому то надо реализовать привычные ОО-концепции, то в ОРСУБД мало средств, а существующие, скажем так, неочевидны и неизящны. По мнению экспертов, они представляют собой лишь синтаксическую надстройку, не являются объектно-ориентированными, значительно нарушают реляционную модель (читайте книги К. Дейта), в них отсутствует проработанность и концептуальная целостность. Как результат, в практике эти средства практически не используются. Попытка не удалась и, возможно, это было одной из причин, почему в конце 90-х термин "impedance mismatch" стал использоваться в нынешнем "фундаментальном" значении.

Параллельно проблему пытались решить и другими способами. Некоторые решили отказаться от SQL и от реляционных СУБД а, заодно, и от реляционной модели вообще. Появились OOСУБД, XML СУБД и, из недавнего, NoSQL СУБД. Каждое новое явление сопровождалось шумихой и обещаниями "серебряной пуля", и каждый раз действо оканчивалось появлением нишевых продуктов, которые позволяли решать какие-то конкретные (иногда достаточно важные) проблемы, но на роль "серебряной пули" никак не тянули.

Виднейший специалист реляционной теории Крис Дейт предложил, наоборот, так называемые "истинно реляционные" СУБД. Конечно, теоретически, это было практически безупречно. Тоже не пошло. Единственная известная мне коммерческая реализация D4 от Dataphor вызвал такой же теоретический интерес и, в общем-то, больше не развивается. Остальные решения трудно назвать иначе, чем пробами пера.

Значительное развитие получили чисто технологические решения. Во-первых, это интеграция технологий, например, Oracle EJB или для MS SQL CLR. Однако факт, что объекты ОО языков теперь находятся рядом с реляционными таблицами, а иногда и внутри этих таблиц, вовсе не означает, что между ними появилось концептуальное единство. Во-вторых, это ORM системы, призванные автоматизировать взаимодействие с СУБД и, тем самым, спрятать его от программиста. И это работает, в смысле, СУБД почти не видно, и цель, вроде бы, достигнута... до тех пор, пока речь не идет о высоконагруженных и/или сложных проектах, или пока не нужны незапланированные отчеты, групповая обработка данных и т.д.. В общем, на этом этапе выясняется, что у реляционных СУБД есть куча преимуществ, которые прятать просто глупо. К группе ORM я (для себя!), отношу и всякого рода ERP- CRM- и т.п. системы. Конечно, они решают иные задачи, у них свои языки, но, так или иначе, они тоже прячут взаимодействие клиента с реляционным сервером (по отношению к серверу, таким клиентом может выступать и промежуточный слой, реализующий бизнес-логику) и испытывают схожие проблемы.

Лирическое отступление про ERP. Где то я читал статью, в которой высококвалифицированный ERP специалист сетовал, что, очень часто, после ухода внедренцев, местные ИТишники начинают в хвост и в гриву дописывать ERP функционал прямо на сервере. Мол, это методологически неправильно, и причина этого безобразия – низкая квалификация местных спецов. Что сказать? Из своего и чужого опыта могу привести примеры, когда перенос реализованной в ERP системе логики (взять хотя бы отчеты) на сервер, давал выигрыш в быстродействии на два порядка, то есть в 100(сто!) раз. Это тоже проблема ежей и ужей. Думаю, что причина миграции логики на сервера именно в этом, и с уровнем квалификации это никак не связано.

По факту, большинство продолжают пользоваться реляционными СУБД, что сопряжено теми же танцами с теми же бубнами… разве что эти бубны иногда разукрашенными новыми наклейками с буквами "ORM". Во многом, ситуация объясняется там, что область систем хранения данных является, наверное, самой консервативной частью IT индустрии. Работающие в ней люди максимально избегают всяких рисков и не идут на революции. Мэйнстрим предпочитает старые проверенные решения, тем более что они имеют свои преимущества, важные для пользователей. При этом очевидно, что владельцы, разработчики и простые пользователи рады были бы получить что-нибудь побыстрее, попроще и подешевле, но индустрия отвечает: "Нельзя, ибо фундаментальная несовместимость. Мы с нею постоянно боремся".

И так год от года. Похоже, что к этой ситуации все начинают привыкать.

Зря.

Комментарии




Необходимо войти на сайт, чтобы оставлять комментарии