Техническая библиотека CITForum.ru CITKIT.ru - все об Open Source Форумы Курилка
Все новости / Все статьи Деловая газета - шквал(!) IT-новостей :: CITCITY.RU
Первая полоса ИТ-Инфраструктура Телекоммуникации Безопасность BI Интеграционные платформы КИС IT-бизнес Ширпотреб Точка зрения

27.06.2017

Новости:


Все новости

Точка зрения

Персистентность Java-объектов: положение дел. Часть 2

Роберто Зикари проинтервьюировал группу ведущих разработчиков решений персистентности по поводу их взглядов на положение дел в области персистентности Java-объектов.

Во второй части панельной дискуссии участвовали следующие эксперты:

Хосе Блейкли (Jose Blakeley), Microsoft

Д-р Хосе Блейкли является членом группы разработчиков подразделения SQL Server компании Microsoft, где он работает над развитием возможностей серверного программирования и расширяемости сервера баз данных, средствами обработки запросов, обеспечением объектно-реляционных средств и приложениями научных баз данных.

До перехода в Microsoft д-р Блейкли был членом технической группы в компании Texas Instruments, являясь основным разработчиком объектно-ориентированной системы управления базами данных Open-OODB, финансировавшейся DARPA.

Рик Каттелл (Rick Cattell), консультант

Д-р Р. Г. Г. «Рик» Каттелл был заслуженным инженером (Distinguished Engineer) в компании Sun Microsystems. В течение более двадцати лет он работал в Sun в качестве менеджера и старшего технического специалиста, а десять лет посвятил исследовательской работе в Xerox PARC и университете Карнеги-Меллон.

Д-р Каттелл более всего известен своим вкладом в областях систем баз данных и промежуточного программного обеспечения, в частности, работами над J2EE, объектно-ориентированными базами данных, объектно-реляционным отображением и интерфейсами баз данных. Он является автором шести книг и нескольких десятков статей. Он был основоположником SQL Access (предшественника ODBC), основателем и председателем Object Data Management Group (ODMG), соразработчиком JDBC.

Вильям Кук (William Cook), University of Texas at Austin

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

До перехода в Техасский университет д-р Кук был техническим директором и соучредителем компании Allegis Corporation. Он являлся главным архитектором нескольких отмеченных наградами продуктов, включая продукт eBusiness Suite в Allegis, Writer's Solution для издательства Prentice Hall и язык AppleScript в компании Apple Computer.

В HP Labs его исследовательская работа концентрировалась вокруг основ объектно-ориентированных языков, включая формальные модели миксинов (mixin), наследования и систем типов объектно-ориентированных языков.

Роберт Грин (Robert Greene), Versant

Обладая более чем 15-летним опытом обеспечения объектно-ориентированных решений, Роберт Грин отвечает за определение общей стратегии и направлений развития объектных баз данных в компании Versant. Роберт – это идейный лидер индустрии, обладающий большим опытом разработки объектно-ориентированных систем и регулярно выступающий на конференциях и семинарах, посвященных языку Java, на темы персистентности объектов и архитектуры J2EE. Роберт является автором публикаций по тематике объектно-реляционного отображения и руководителем проекта JSR220 ORM в рамках инициативы по созданию инструментария для EJB на платформе Eclipse.

Элан Сантос (Alan Santos), Progress Software

В настоящее время Элан является менеджером по продукции в компании Progress Software, помогающим определить будущую роль ООСУБД на предприятиях. До перехода в менеджмент по продукции он был ведущим инженером в группе ООСУБД ObjectStore, ответственным за совершенствование продуктов ObjectStore C++ и ObjectStore Java. До этого он проработал несколько лет ведущим консультантом в компании Object Design Inc., разрабатывая, реализуя и поддерживая высокопроизводительные решения на основе ООСУБД, направленные на преодоление разнообразных проблем заказчиков, в число которых входили как мировые компании, входящие в рейтинг Fortune Global 500, так и небольшие начинающие компании.

Вопрос 1: По-прежнему ли перед нами стоит «проблема потери соответствия» (impedance mismatch problem)?

Хосе Блейкли: Проблема потери соответствия существует с тех пор, как стали различаться модели данных, применяемые для долговременного хранения данных с использованием файловых систем или систем управления базами данных, и модели данных, используемые для написания программ обработки этих данных (C++, Smalltalk, Visual Basic, Java, C#).

Сегодня я вижу два типа проблем потери соответствия: (1) проблема потери соответствия приложений и (2) потеря соответствия в службах данных. На решение проблемы потери соответствия первого типа в середине 1990-х гг. были направлены разработки языков программирования, поддерживающих персистентность объектов (Persistent Programming Language), и ООСУБД, в которых системы типов языков программирования, таких как C++, Smalltalk и Lisp, принимались в качестве моделей данных для долговременно хранимых данных. Сегодня большая часть корпоративных данных сохраняется в реляционных базах данных. В большинстве серьезных приложений, являются ли они комплексным программным обеспечением (например, CRM, ERP) или сделаны по заказу, реализуется уровень доступа к данным, располагающийся между базой данных и приложением и разрабатываемый для преодоления потери соответствия между реляционной моделью данных и объектной моделью, которая используется в приложении. Этот уровень косвенности может содержать около 40% кода приложений (иногда больше).

Второй тип потери соответствия проявляется в том способе, с использованием которого создаются службы данных, такие как репликация, генерация отчетов, бизнес-аналитика (OLAP). В этих службах данных также поддерживается персистентность данных или производится доступ к реляционным данным, и требуется преодоление семантического разрыва между реляционной моделью и семантическими моделями более высокого уровня, используемыми в службах данных. Мы полагаем, что такая семантическая модель должна быть близка к модели «сущность-связь», введенной Питером Ченом в середине 1970-х гг.

В софтверной индустрии создаются инструментальные средства, предназначенные для минимизации потери соответствия приложений с использованием технологий объектно-реляционного отображения. Кроме того, в языки программирования включаются ориентированные на множества декларативные программные выражения как естественные конструкции внутри этих языков, что позволяет еще больше минимизировать, а в некоторых случаях и полностью устранить потерю соответствия. Примерами этого являются расширения Language Integrated Query (LINQ) и выражения запросов в C# 3.0 и Visual Basic 9.0. Дальнейшие подробности можно найти в статье Next-Generation Data Access: Making the Conceptual Level Real.

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

Вильям Кук: Да, у нас по-прежнему имеется проблема потери соответствия. Я полагаю, что в основном потеря соответствия возникает из-за интеграции процедурных языков и языков запросов, а не из-за используемых типов данных (реляционных и объектных). Это восходит к оригинальной статье Дэвида Майера (David Maier) «Representing database programs as objects», в которой он говорил, что проблемой являются поэлементные, а не массовые операции в языках программирования. Поэтому ключевым соображением является то, что потеря соответствия может возникнуть даже при использовании объектно-ориентированного языка и объектно-ориентированной базы данных. Эта проблема возникает, если в ООСУБД поддерживается язык запросов, а в языке программирования этот язык запросов невозможно использовать естественным образом.

LINQ представляет собой пример гибридного функционально-процедурного языка, и это шаг в правильном направлении. Однако эта интеграция пока не является бесшовной. Имеются проблемы с модульностью при попытках оптимизации запросов за пределами границ процедур.

Кроме того, трудно загружать связанные объекты с использованием конструкции LoadWith в LINQ или ключевого слова FETCH в Hibernate. То, какие связанные объекты следует загрузить, зависит от способов использования результатов запросов. Один и тот же запрос может использоваться в разных контекстах, для которых требуются разные стратегии загрузки. Кроме того, использование результатов запросов часто содержится в другом слое приложения: запрос часто располагается в слое бизнес-логики, а результаты запроса используются в слое интерфейса с пользователями. Например, функцией бизнес-логики может быть загрузка данных о служащих, а в пользовательском интерфейсе может определяться, какую информацию о служащих следует отобразить на отдельных страницах.

Роберт Грин: Безусловно. Классическую «проблему потери соответствия» можно в общих чертах определить как бремя, возложенное на программистов, которые принуждаются работать при наличии несовместимых парадигм программирования и хранения данных. По мере развития инструментальных средств потеря соответствия в этом отношении сокращается, но пытались ли вы отобразить на реляционную базу данных приложение, основанное на использовании более двухсот классов? Любой, кто делал это, знает, что по-прежнему имеется потеря соответствия.

Кроме того, я бы рискнул утверждать, что потеря соответствия – это проблема, являющееся не просто бременем для разработчиков. Это проблема денег. Для выполнения прямых и обратных отображений требуется огромная работа процессора. Сегодня мы хорошо понимаем, что использование компьютера стоит дороже его покупки. Если при устранении потери соответствия можно сократить размер производственной системы вдвое, то эта проблема – денежная. Для крупномасштабных систем возникает гигантская экономия. Сокращение размера на 50% означает уменьшение расходов на лицензии и на сопровождение системы, сокращение энергопотребления и, в конце концов, сокращение расходов на хостинг. Представьте, что было бы, если бы eBay, Amazon, Facebook, LiveJournal и т.д. сократили свои производственные системы на 50%. Это не абстрактные рассуждения, а то, с чем я лично сталкивался при работе с заказчиками Versant.

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

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

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

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

Вопрос 2: Как бы вы позиционировали различные варианты обеспечения персистентности объектов в новых проектах, если принимать во внимание то, что используется в индустрии?

Хосе Блейкли: Для многих приложений и служб данных создается собственный проприетарный уровень доступа к данным, разрабатываемый для преодоления проблемы потери соответствия. В последние пять лет возрастает популярность технологий объектно-реляционного отображения, подобных Hibernate. В компании Microsoft мы отслеживаем проблемы потери соответствия приложений и служб данных и полагаем, что имеется потребность в концептуальной модели данных более высокого уровня для повышения уровня абстракции баз данных над реляционной моделью. Эта концептуальная модель представляет собой нечто, близкое к модели «сущность-связь». Это обогащенная структурная модель, включающая понятия сущности, связи и наследования, но не затрагивающая аспекты поведения, такие как методы.

Вокруг концептуальной модели, основанной на сущностях, может быть построено несколько тонких объектных слоев, специфичных для конкретных языков программирования. В таком объектном слое появляются методы, семантика ссылок и кэширования объектов в духе, свойственном конкретному языку программирования. В Microsoft применяемая конкретизация концептуальной модели называется моделью данных сущностей (Entity Data Model, EDM), а поддерживающая ее среда времени выполнения – каркасом сущностей (Entity Framework, EF). В EDM имеется язык запросов EntitySQL, который предназначен для формулировки запросов к моделям, определенным с использованием EDM.

В EF реализуются все отображения сущностей в реляционные данные. Обеспечивается отображение данных из таблиц базы данных в сущности и наоборот с учетом возможности выполнения операций обновления базы данных. EF автоматически транслирует EntitySQL-запросы над наборами сущностей в базовые SQL-запросы над таблицами. Уровень объектных служб, надстраиваемый поверх EDM, обеспечивает связывания, специфичные для конкретного языка, и позволяет формулировать LINQ-запросы над коллекциями объектов. Мы ожидаем, что со временем EDM, EntitySQL и EF будут естественным образом поглощены реляционными системами.

Подробности можно прочитать в следующих материалах:

1. Anatomy of the ADO.NET Entity Framework;
2. Compiling Mappings to Bridge Applications and Databases;
3. Lost In Translation: Formalizing Proposed Extensions to C#;
4. A description of Entity SQL.

Рик Каттелл: Тремя наилучшими вариантами для Java являются JDBC, объектно-реляционное отображение и ООСУБД. В течение последних десяти с лишним лет я работаю во всеми тремя этими подходами и их частными случаями, например, JDO и JPA API для объектно-реляционного отображения. У каждого из этих подходов имеются свои преимущества.

Вильям Кук: Я ушел из индустрии и теперь работаю в университете. С точки зрения языков программирования LINQ является большим шагом вперед в направлении интеграции массовой обработки данных с процедурными языками. Я исследую эту проблему в контексте языка Java. Практическая работа над Java, включая мою собственную работу, часто подразумевает, что язык нельзя изменять, и это оказывает существенное влияние на диапазон возможных разработок. Это также приводит к повышению уровня использования рефлексии и динамической кодогенерации, что может усложнять разработку. Вот некоторые проекты, над которыми я продолжаю работать совместно с представителями индустрии.

AutoFetch используется для автоматического определения на основе предыдущего поведения программ того, какие данные следует загрузить при выполнении запроса. Можно считать, что запрос состоит из двух частей: условие выборки и упреждающее чтение связанных объектов. AutoFetch управляет частью упреждающего чтения и работает очень хорошо. Эта идея является достаточно общей и может применяться к любому интерфейсу базы данных и языка программирования, включая LINQ. Реализована и выпущена соответствующая версия Hibernate.

В настоящее время Роб Бигрэйв (Rob Bygrave) реализует AutoFetch для Ebean ORM. Понятно, что AutoFetch занимается частями конструирования запросов, связанными только с оптимизацией загрузки данных, организованной беспорядочно в LINQ и Hibernate.

Я работал над Native Queries с компанией db4objects. В этом средстве для определения условий запросов используются методы Java во многом подобно тому, как в LINQ используются лямбда-функции. Для реализации Native Queries не требуются синтаксические изменения Java; обеспечивается оптимизация запросов и динамические запросы. Все это можно объединить с AutoFetch, но пока, насколько я знаю, это не сделано.

Наконец, я работаю над более долговременным проектом по автоматическому извлечению законченных запросов из Java-программ. В этой работе используется статический анализ для извлечения из кода условий упреждающего чтения и выборки. Подход не слишком хорошо работает для запросов с агрегатами. И его тоже можно объединить с AutoFetch и явными запросами (как в LINQ) для создания более мощной системы. Для достижения такой полной интеграции требуется еще несколько лет.

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

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

Поэтому, если делается что-то относительно простое и маломасштабное, то имеет смысл использовать простейшие средства, возможно, нечто вроде Ajax над Web-сервером и Java Content Repository API (JCR API). При наличии требований среднего уровня нужно, прежде всего, понять, в чем состоит их умеренность, и затем применить для разработки что-нибудь более сильное, например, Ajax над сервером приложений, или Spring, или какой-нибудь другой каркас, используя при этом некоторое решение объектно-реляционного отображения для предпочтительной РСУБД. Если имеются высокие требования к масштабируемости, то, вероятно, разумно прибегнуть к решению на основе SOA с использованием ESB или какого-либо другого асинхронного каркаса потоков работ, опираясь на слой горизонтально разделяемых данных. При выполнении такой работы полным счастьем является построение производственной системы, свободной от проблемы потери соответствия, без затрат, соизмеримых с теми, которые требуются для построения очередного танкера компании Chevron.

Конечно, для полноты следует отметить, что имеется и другой край этого спектра. Что если требуется сохранять какие-то данные в мобильном телефоне или смарт-карте? Чем плоха сериализация Java? Может быть, ничем, но, возможно, потребуются запросы, так что в действительности потребуется встраиваемая база данных. Имеющиеся факторы и возможные решения персистентности достаточно многочисленны и заслуживают глубокого обдумывания.

О, Боже, я думал, что все сказал, а забыл обсудить хранилища XML-данных. Но сказанного и так достаточно.

Элан Сантос: Думаю, что, вообще говоря, в софтверном сообществе принимаются во внимание два варианта: реляционный и не реляционный.

С небольшой долей преувеличения замечу, что никто и никогда не отказывался от выбора реляционной базы данных. Для большинства организаций реляционные базы данных являются выбором de-facto, если не de-jure. В типичных случаях интеграции с существующими источниками данных, или когда технологические требования превосходятся другими соображениями, такими как потребность в простом получении специалистов, знакомых с данной технологией, или когда единственно доступным является путь наименьшего сопротивления, приемлемым вариантом, конечно, является обеспечение персистентности Java-объектов путем их отображения в реляционное хранилище. В этом контексте в число пригодных средств я включаю как JDBC, так и объектно-реляционное отображение.

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

Что касается не реляционных вариантов обеспечения персистнентности объектов, то я бы сказал, что в этой области наблюдаются новые продвижения. К числу примеров относятся CouchDB и FeatherDB, ориентированные на хранение документов, службы данных, такие как Amazon SimpleDB и Google App Engine, а также заново пробудившийся интерес к ООСУБД, включая новых участников этой индустрии, таких как компания db4o.

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

Вопрос 3: Каково ваше мнение о достоинствах и недостатках имеющихся решений?

Хосе Блейкли: В последние тридцать с лишним лет разработчики приложений использовали концептуальные модели (например, ER-диаграммы, UML) на ранних стадиях жизненного цикла разработки приложений.

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

Для ER-модели никогда не было реализации поддержки времени исполнения. Технологии объектно-реляционного отображения, такие как Hibernate или ADO.NET Entity Framework, направлены на поддержку отображения во время исполнения приложений, обеспечивая возможность абстрагирования приложений от проблемы объектно-реляционного отображения. В ADO.NET EF предпринимается еще один шаг за счет обеспечения обогащенной концептуальной абстракции сущностей, основанной на EDM, и абстракции объектов для объектов .NET. Языком запросов для EDM является EntitySQL. Языком запросов для объектов является LINQ.

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

Рассмотрим фрагмент кода приложения, направленный на получение имени, идентификатора и даты приема на работу всех продавцов, принятых на работу до некоторой даты. Этот фрагмент кода обладает несколькими недостатками, не имеющими особого отношения к бизнес-вопросу, на который требуется ответить. Во-первых, хотя запрос можно сформулировать на естественном языке очень лаконично, оператор SQL является довольно многословным, и для его формулировки разработчик должен знать нормализованную реляционную схему, чтобы специфицировать соединение нескольких таблиц для сбора соответствующих столбцов из таблиц SContacts, SEmployees и SSalesPersons. Кроме того, при любом изменении схемы основной базы данных потребуются соответствующие изменения в приведенном ниже фрагменте кода.

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

Хотя этот код написан с использованием ADO.NET 2.0, его особенности и недостатки свойственны любому другому API для доступа к реляционным данным, например, ODBC, JDBC и OLE-DB.

void EmpsByDate(DateTime date) {
using( SqlConnection con =
 new SqlConnection (CONN_STRING) ) {
  con.Open();
  SqlCommand cmd = con.CreateCommand();
  cmd.CommandText = @“SELECT SalesPersonID,
FirstName, HireDate
       FROM SSalesPersons sp INNER JOIN SEmployees e ON
sp.SalesPersonID = e.EmployeeID
       INNER JOIN SContacts c ON e.EmployeeID =
c.ContactID
       WHERE e.HireDate < @date”;
cmd.Parameters.AddWithValue(“@date”,date);

DbDataReader r = cmd.ExecuteReader();
 while(r.Read()) {
  Console.WriteLine(“{0:d}:\t{1}”,
   r.GetDateTime(0), r.GetString(1));
}
}
}

Эквивалентная программа на концептуальном уровне выглядит следующим образом:

void EmpsByDate (DateTime date) {
 using( EntityConnection con =
  new EntityConnection (CONN_STRING) ) {
  con.Open();
  EntityCommand cmd = con.CreateCommand();
cmd.CommandText = @“SELECT VALUE sp FROM SSalesPersons sp WHERE
sp.HireDate < @date”;
  cmd.Parameters.AddWithValue(“date”, date);
  DbDataReader r = cmd.ExecuteReader();
  while (r.Read()) {
   Console.WriteLine(“{0:d}:\t{1}”,
    r.GetDateTime(0), r.GetString(1));
}
}
}

Оператор SQL значительно упростился – от пользователя больше не требуется знание точной схемы базы данных. Кроме того, логику приложения можно изолировать от изменений в схеме основной базы данных. Однако этот фрагмент все еще основан на использовании символьной строки, в нем по-прежнему не используются преимущества типизации языка программирования, и запрос возвращает слабо типизированные результаты. Путем добавления тонкой объектной оболочки вокруг сущностей и использования расширений LINQ языка C# можно написать эквивалентную функцию без эффекта потери соответствия:

void EmpsByDate(DateTime date) {
 using (AdventureWorksDB aw = new AdventureWorksDB()) {
  var people = from p in aw.SSalesPersons where p.HireDate < date select p;
  foreach (SalesPerson p in people) {
   Console.WriteLine(“{0:d}\t{1}”,
       p.HireDate, p.FirstName );
}
}
}

Запрос выглядит просто; приложение (в значительной степени) изолировано от изменений схемы основной базы данных; запрос подвергается полному контролю типов компилятором C#. Кроме выполнения запросов, имеется возможность взаимодействия с объектами и выполнения над объектами обычных операций Create, Read, Update и Delete (CRUD).

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

Рик Каттелл: Я думаю, что участники первой части дискуссии уже предоставили хорошие аргументы за и против своих любимых технологий.

Вильям Кук: Моя текущая точка зрения является академической в том смысле, что я гляжу на несколько лет вперед, а не на текущую технологию. Мое ощущение (надежда?) состоит в том, что сообщество Java наконец объединяется вокруг нескольких решений (для корпоративных и встраиваемых разработок), переставая вести бесконечную внутреннюю борьбу относительно слегка различающихся, но совместимых подходов.

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

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

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

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

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

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

Вопрос 4: Считаете ли вы, что средства объектно-реляционного отображения являются пригодным решением проблемы «персистентности объектов»? Если да, то почему? Если нет, то почему?

Хосе Блейкли: Да, считаю. См. ответ на вопрос №3.

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

Вильям Кук: Да, я думаю, что всегда будет иметься уровень отображения. Эти средства следовало бы называть средствами «объектно-персистентного отображения», поскольку они отображают объекты в используемую базу данных какого-либо вида. Одним из оснований моей убежденности является то, что я не верю в хранение в базе данных полных объектов – методы и код не следует долговременно хранить вместе с данными. В результате всегда придется добавлять к данным поведение при их загрузке в программу.

Роберт Грин: Я полагаю, что ответом является «правильное средство для конкретного случая». Не бывает черно-белых ответов «да» и «нет», мир не настолько прост. Средства объектно-реляционного отображения являются вполне пригодными и работают лучше JDBC, над которым имеются вручную закодированные уровни персистентности. Если вам досталась существующая базы данных с реляционными данными, и вы хотите предоставить какую-то новую возможность, то проще произвести обратное проектирование реляционной схемы и быстро с этим разделаться. У вас имеется корпоративная лицензия Oracle и 15 человек, знающих Hibernate, и вам не требуется получить нечто масштабируемое до миллионов пользователей (не то, чтобы не требуется, но здесь опять действует денежный эффект).

Однако в жизни любого разработчика наступает момент, в который он должен спросить себя, не являются ли его модели достаточно сложными для того, чтобы отказаться от файлов отображения Hibernate/JPA/JDO? Не сэкономит ли он время для выхода на рынок или деньги, требуемые для управления производственной системой, если откажется от уровня объектно-реляционного отображения и станет использовать ООСУБД? Это шкала с оттенками серого цвета, поскольку каждый человек задается этим вопросом в индивидуальный для его момент времени. Этот момент зависит от того, предпочитает ли данный человек придерживаться того, что знает, опасается ли он неизвестного, никогда не использует новую технологию первым (является поздним последователем), или же он легко принимает изменения, интересуется лучшими в своем классе решениями, любит быть ранней пташкой и первым получать своего червяка (является первопроходцем).

Являются ли они пригодными? А что такое пригодность? Я могу создать все что угодно с использованием сегодняшней технологии. Умные люди поймут, что я говорю не о том, что пригодно, а о том, что лучше всего. При использовании «пригодного» решения создание приложения займет шесть месяцев, и для его работы потребуется 100 серверов, а если применить «наилучшее» решение, то разработка займет три месяца, и для использования приложения хватит десяти серверов. Здесь действует денежный эффект.

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

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

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

Вопрос 5: Считаете ли вы, что системы реляционных баз данных являются пригодным решением проблемы «персистентности объектов»? Если да, то почему? Если нет, то почему?

Хосе Блейкли: Реляционные системы являются стандартом de facto для долговременного хранения данных. Со временем модель данных, поддерживаемая коммерческими реляционными системами, будет усилена для поддержки обогащенных концептуальных моделей, таких как EDM. Кроме того, язык запросов реляционных систем будет эволюционировать во что-то близкое к EntitySQL.

Рик Каттелл: Нет, они не являются хорошим решением из-за проблемы потери соответствия. Но, как я упоминал ранее, у многих программистов нет возможности выбора системы базы данных, и при выборе решения персистентности имеются другие ограничения.

Вильям Кук: Я представляю себе SQL языком ассемблера систем баз данных. Он напоминает языки ассемблера, которые до наступления эпохи RISC-процессоров разрабатывались с учетом удобства восприятия людьми. Но современная тенденция такова, что большая часть SQL будет генерироваться компьютерами. Старая мудрость, заключающаяся в том, что выражения SQL нужно оптимизировать вручную, и что нужно писать хранимые процедуры, справедлива теперь только в очень редких случаях. Теперь нужно было бы проанализировать распространенные паттерны коммуникаций между программой и базой данных и изменить SQL таким образом, чтобы он стал более удобным целевым языком для представления автоматически генерируемых запросов. Это именно то, что было сделано в подходе RISC на границе между компиляторами и архитектурой. Одним из примеров является возврат запросами более сложных структур, чем простые отношения. Тот факт, что из запросов могут возвращаться только таблицы, годами представлял проблему, и это сдерживает развитие. Высокоуровневые генераторы запросов для эффективной загрузки нескольких связанных наборов данных вынуждены заниматься акробатикой. Это нужно изменить.

Роберт Грин: Я думаю, что в качестве ответа на этот вопрос можно повторить мой ответ на предыдущий вопрос. Мы живем в мире полутонов. Имеются ситуации, в которых я, гуру в области объектных баз данных, рекомендовал бы пользоваться реляционными базами данных. Да, они пригодны, но не всегда представляют собой правильное средство в конкретной ситуации. И в реальных жизненных условиях, как бы мне не хотелось видеть больше новаторов и первопроходцев, имеется масса людей, которые боятся неизвестного. Поэтому линия раздела, на которой люди делают выбор между пригодными и лучшими в своем классе средствами, будет, безусловно, оставаться более близкой к пригодным средствами, чем многим из нас кажется разумным.

Элан Сантос: Я думаю, что уже ответил на этот вопрос раньше.

Вопрос 6: Считаете ли вы, что системы объектных баз данных являются пригодным решением проблемы «персистентности объектов»? Если да, то почему? Если нет, то почему?

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

Рик Каттелл: Да, объектные базы данных разрабатывались специально для решения проблемы персистентности объектов.

Вильям Кук: Я не являюсь ни реляционным, ни объектно-ориентированным пуристом. Когда я смотрю на OQL, мне кажется, что в этом языке не так уж много «объектной ориентированности». В нем предполагается наличие модели данных, в которой записи явным образом связываются, в то время как в реляционной модели ссылки являются неявными и основываются на внешних ключах. Но почти все реляционные базы данных проектируются с использованием модели «сущность-связь», которая позже была перенята в UML и переименована в «диаграммы классов». В OQL разрешается конструирование произвольно вложенных коллекций записей в качестве результата запроса, в то время как в реляционной модели исторически требуется возвращать единственное множество записей. Однако системы реляционных баз данных могли бы возвращать несколько множеств записей или поддерживать вывод данных в других формах. Расширения для поддержки XML, внесенные во многие РСУБД, значительно приближают их функциональность к возможностям OQL. Может быть, это делает их «объектно-ориентированными»?

Я не разработчик СУБД, но полагаю, что ООСУБД и РСУБД начинают становиться довольно похожими при взгляде на них со стороны, если в них реализуются ключевые возможности баз данных оптимизации запросов, кэширования и ACID-транзакций. Не слишком сильно различаются OQL и SQL. Возможно, их былые различия уже не слишком существенны.

Роберт Грин: И еще раз: нет черно-белых ответов. Да, они пригодны, но не во всех случаях являются правильным средством. Как говорилось ранее, выбор между объектной и реляционной базой данных зависит от многих факторов, от конкретных людей, от того, являются ли они поздними последователями или первопроходцами. Я считаю, что, вообще говоря, по мере возрастания сложности приложений и объемов обрабатываемых ими данных объектные базы данных становятся более жизнеспособным вариантом.

Здесь одной из основных проблем является то, что в мире на основе реляционной технологии построено множество систем, и эти системы требуется расширять и интегрировать. Эта работа всегда является трудной, и использование объектной базы данных усложняет задачу хотя бы в том, что усложняются понятия на концептуальном уровне. Реальность состоит в том, что теперь имеются решения для Java, в которых могут совместно использоваться оба вида систем. У компании Versant имеются решения, в которых POJO может использоваться и в объектной, и в реляционной базах данных. Поэтому в новых системах их можно легко и бесшовно интегрировать. По мере того, как мир двигается по направлению к архитектурам, подобным SOA, в которых ресурсы относительно независимы от реализации, будет все легче совершать выбор по соображениям типа «денежного эффекта».

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

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

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

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

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

Вопрос 7: Какие исследования и разработки в области персистентности объектов вы считали бы уместными в следующие 12 месяцев?

Хосе Блейкли: Наверное, 12 месяцев – это слишком короткий промежуток времени. Через 3-5 лет я хотел бы видеть технологии, подобные EDM, EntitySQL и EF, включенными естественным образом в системы реляционных баз данных. Мне также хотелось бы, чтобы новшества, подобные LINQ, стали частью языков хранимых процедур следующего поколения, естественным образом поддерживаемых системами баз данных.

Рик Каттелл: Меня разочаровывает медленный прогресс в области API персистентных объектов для Java. Прогрессу мешает политика: кроме собственных пристрастий, у поставщиков имеется сильный интерес к включению в состав решения конкретных технологий. Например, на стандартизацию OMG Persistence Service и EJB 2.0 Persistence сильное влияние оказывали IBM и Oracle, и обе спецификации оказались бедствием для программистов (IMHO).

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

Вильям Кук: Я бы хотел, чтобы основные поставщики СУБД реализовали OQL (или некоторый его вариант, подобный HQL) в качестве естественного интерфейса к своим реляционным базам данных. Конечно, в ответ я услышу крики гнева по поводу того, что это нарушает реляционные догмы, завещанные основоположниками. Но это меня не волнует. Было бы гораздо проще сохранять и загружать объекты, если бы формат вывода базы данных был более гибким. Результатом запроса должна быть полная мини-база данных, а не отдельный компонент базы данных.

Мне также хотелось бы увидеть эксперименты Microsoft с другими способами обработки конструкции «LoadWith», подобными AutoFetch или Query Extraction. (Оговорка: в этом состоит суть двух исследовательских проектов моих студентов; мне не стоит просить за это прощения.) Может быть, они смогут предложить что-нибудь лучшее. Но им стоит попробовать, поскольку имеющееся решение не масштабируется для больших программ.

Наконец, я думаю, что сообществу Java нужно понять, чем они могут ответить на инициативу LINQ. Они могут скопировать решение Microsoft, как скопировали MTS (Microsoft Transaction Server) при создании EJB. Или они могут организовать исследовательскую работу для поиска лучшего решения. История LINQ не закончена, так что здесь имеется благоприятная возможность.

Роберт Грин: Я думаю, что требуемые исследования уже выполняются. Совершенно поразительно, что люди ищут новые способы скрыться за абстракциями JDBC для обеспечения персистентности Java-объектов. Исследовательской проблемой, близкой к персистентности объектов, но настолько же применимой и к другим уровням архитектуры приложений, является отображение моделей. При использовании объектных баз данных к этой области имеют отношение эволюция и поддержка версий схемы. Это еще одна разновидность потери соответствия, которая существует и должна приниматься во внимание в исследованиях и практике.

Эта потеря соответствия проявляется в том способе, который используется для реализации уровня представления, отличающегося от уровня бизнес-логики и выглядящего по-разному в разных контекстах потоков работ и, конечно, при использовании разных ресурсов данных. Проблема еще более усугубится, если в нашу практику программирования начнут входить проблемно-ориентированные языки. Для преобразований XML имеется XSLT, но простого перевода объектов используемого языка в формат XML для получения хорошей технологии преобразований будет недостаточно.

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

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

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

Хосе Блейкли: Разработка EDM, EntitySQL, EF runtime и LINQ заняла 3-4 года. Теперь, когда эти средства поставляются в составе Visual Studio 2008, мне хотелось бы, чтобы соответствующие технологии применялись в качестве абстракций персистентности в новых проектах. Я хотел бы собрать информацию от потребителей и данные о реальных приложениях, чтобы улучшить все эти новые технологии и сопутствующие им инструментальные средства разработки для еще большего повышения производительности труда программистов.

Рик Каттелл: JDO!

Вильям Кук: В течение более чем десяти лет я следую за устойчивым потоком API баз данных. ODBC, DAO, RDO, OLE DB, MTS, JDBC, ADO, ADO.NET, JDBC, EJB 1, JDO, EJB 2, Hibernate, Linq, SDO, JPA. Не говоря уже о десятках (сотнях) других решений с открытыми исходными текстами или доморощенных средств. Я не думаю, что этот поток вскоре иссякнет. Это действительно сложная проблема, и почти все решения являются частичными или неполными в каком-либо существенном отношении.

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

Роберт Грин: Если бы я был всемогущим, то в типичном проекте использовалось бы в точности то, чего бы мне хотелось, и пусть звали бы меня чародеем ;-)

Более серьезно, если бы я имел существенное влияние на принятие технологии в течение последних десяти лет, то, я думаю, мир не слишком бы отличался от того, как он выглядит сегодня, хотя пропорции изменились бы. Я имею в виду, что более десяти лет тому назад реляционные базы данных были вездесущими, но, тем не менее, множество данных хранилось в старинных сетевых базах данных, файлах ISAM, на мейнфреймах и т.д. Как говорится в старой поговорке, куда данные попадают, там они и остаются. И сегодня во многих системах для управления данными используются мейнфреймы. Поэтому все это осталось бы и в измененном мною мире. Однако если бы у меня было существенное влияние, то к настоящему моменту я хотел бы видеть не имеющееся сегодня соотношение 95/5 числа внедрений технологий реляционных и объектных баз данных соответственно, а что-нибудь близкое к 50/50 ;-) Объектные базы данных можно было бы использовать в очень многих простых системах.

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

Вопрос 9: Можете ли вы сказать что-нибудь еще на эту тему?

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

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

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

Я также думаю, что мы подошли к тому времени, когда нам требуется новая парадигма. Прежнее соперничество больше не имеет смысла. Я работаю в области модельно-ориентированной разработки (model-driven development) и стараюсь помочь тому, чтобы этот подход стал полноправной парадигмой программирования. При его использовании «методы» и «данные» могут быть, в конечном счете, интегрированы некоторым новым образом. Если это получится, то со временем проблема потери соответствия объектно-ориентированных баз данных будет решена, она станет просто неуместной. Мы живем в интересное время. Я надеюсь, что вы найдете эти замечания полезными и, возможно, провокационными. В конце концов, для этого и проводятся подобные панельные дискуссии.

Роберт Грин: Нам всем было бы намного лучше, если бы мы всего лишь использовали в каждой конкретной ситуации правильные средства. Чтобы забить маленький гвоздик, не нужна кувалда. И наоборот, трудно свалить дерево перочинным ножом. Нужно понять, что за приложение требуется построить, и выбрать простейшее решение, не связывающее руки и не наносящее денежного ущерба. Не следует бояться применять новые инструментальные средства, они могут помочь существенно сократить требуемый объем работы.

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

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

Спасибо за приглашение к участию в дискуссии.



Последние комментарии:

Самое интересное:


© 2004–2009 Проект CITCITY.ru