Обзор средств объектно-реляционной проекции (ORM) для платформы .NET

Что такое ОРП (Object Relational Mapping - ORM), зачем и с чем его едят, обзор имеющихся на рынке продуктов для .NET.

Зачем это нужно

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

Объектная и реляционная модели ортогональны. Это значит, что они моделируют одну и ту же сущность, но с разных сторон, под разными, я бы сказал перпендикулярными углами зрения. Реляционная модель акцентирует свое внимание на структуре и связях сущностей, объектная - на их свойствах и поведении. Цель использования реляционной модели - информационное моделирование, выделение существенных для нас атрибутов, сохранение их значений и последующего поиска, обработки и анализа. Цель использования объектной - моделирование поведения, выделение существенных для нас функций и последующего их использования. Между моделями есть пересечение - структурные сущности, которые по-разному в этих моделях отражаются. Для того, чтобы отобразить артефакты реляционной модели в артефакты же объектной в наших программах и требуется средство объектно-реляционной проекции - ОРП или широко распространенное англоязычное обозначение - ORM (Object Relational Mapping).

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

Рассмотрим для сравнения код с использованием ADO.NET и ОРП.

ADO.NET

SqlConnection myConnection = new 
SqlConnection(myConnectionString);
// Создаем два объекта DataAdapater для таблиц Customers и Orders
SqlDataAdapter mySqlDataAdapter = new SqlDataAdapter("select * from customers", 
myConnection);
SqlDataAdapter mySqlDataAdapter1 = new SqlDataAdapter("select * from orders", 
myConnection);
DataSet myDataSet = new DataSet();
object DataRow myDataRow;
// Создаем объект command builder для работы с таблицами Customers и Orders
SqlCommandBuilder mySqlCommandBuilder = new SqlCommandBuilder(mySqlDataAdapter);
SqlCommandBuilder mySqlCommandBuilder2 = new SqlCommandBuilder(mySqlDataAdapter1);
// Заполняем DataSet-ы
mySqlDataAdapter.Fill(myDataSet,"Customers");
mySqlDataAdapterl.Fill(myDataSet,"Orders");
// Добавляем связь между таблицами
myDataSet.Relations.Add("CustOrders", myDataSet.Tables["Customers"].Columns["CustomerId"], 
myDataSet.Tables["Orders"].Columns["CustomerId"]);
// Меняем значения поля ContactName первой строки Customer
myDataSet.Tables["Customers"].Rows[0] ["ContactName"] ="Peach";
// Добавляем строку в Customer и инициализируем поля
myDataRow = myDataSet.Tables["Customers"].NewRow();
myDataRow["CustomerId"] ="TST4";
myDataRow["ContactName"] = "New Contact Name";
myDataRow["CompanyName"] = "New Company Name";
myDataSet.Tables["Customers"].Rows.Add(myDataRow);
// Добавляем новый Заказ для данного Клиента
DataRow orderRow = myDataSet.Tables["Orders"].NewRow();
orderRow["OrderDate"] = DateTime.Now;
// Устанавливаем связь "родитель-потомок"
orderRow.SetParentRow( myDataRow, myDataSet.Relations["CustOrders"]);
// Добавляем строку в DataSet
myDataSet.Tables["Orders"] .Rows.Add(orderRow);
// Вносим изменения в базу данных
mySqlDataAdapter.Update(myDataSet, "Customers");
mySqlDataAdapterl.Update(myDataSet, "Orders");

ОРП

// Создаем новый объект DataManager и 
соединяемся с базой данных
// Объект Config берет данные из стандартного файла конфигурации App.config
DataManager data = new DataManager(Config.Dsn);
// Создаем коллекцию объектов Клиент(Customers) и связанных с ними Заказов и 
заполняем ее данными из базы данных
CustomersCollection customers = data.GetCustomersCollection (FetchPath.Customers.Orders);
// Изменяем атрибут ContactName для Клиента с CustomerId = "ALFK1"
customers.FindByCustomerID("ALFK1").ContactName = "Peach";
// Создаем нового Клиента
// В объектной модели атрибуты CustomerId и CompanyName описаны, как 
обязательные для заполнения
Customers customer = data.NewCustomers( "Tst7", "Olero Software, Inc.");
customer.ContactName = "Tech Support";
// Создаем новый Заказ для Клиента
Orders order = customer.NewOrders();
order.Customer = customer;
order.OrderDate = DateTime.Now;
// Вносим изменения в базу данных
data.CommitAll();

Преимущества подобного подхода очевидны:

  • рутинный код манипуляции данными в программах уменьшается в среднем на треть по сравнению с работой через классические табличные DataSet
  • в архитектуре приложения можно четко разделить слой хранения данных, обеспечиваемый СУБД, и слой прикладных объектов (или "бизнес-объектов", business objects layer).

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

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

Портрет "идеального" ОРП с точки зрения разработчика

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

  • Платформа .NET. Я не хочу обидеть поклонников Java, но в данной статье я речь пойдет только о продуктах для платформы Microsoft. Тем более, что в мире Java продукты этого класса находятся в более зрелом состоянии.
  • Интеграция с Visual Studio. Средства "малой механизации" разработки, встроенная документация и шаблоны не будут лишними.
  • Наличие среды моделирования. UML является стандартом для объектного моделирования, поэтому вместо ручного написания кода сотни классов и последующего управления этой оравой желательно иметь возможность делать это "легким движением мышки" на диаграмме классов. Но об этом чуть позже.
  • Собственно ОРП. Фреймворк, оформленный в виде библиотеки (сборки), готовый к последующему распространению вместе с вашей гениальной программой.
  • Изолированность. В идеале, ОРП должен уметь присоединиться к уже существующим набору классов и/или схеме БД не меняя ни того, ни другого. Чтобы не пришлось вам добавлять в БД новые поля, а классы в обязательном порядке наследовать от некоего "базового объекта" или, тем более, интерфейса с необходимостью его реализации.
  • Поддержка нескольких СУБД. Чтобы охватить больший круг потенциальных покупателей, ваша гениальная программа должна уметь хранить данные в тех СУБД, которые являются корпоративным стандартом Клиента.
  • Прямой и обратный инжиниринг с "ручным управлением". В идеальном варианте вы начинаете разработку с чистого листа. Тогда вам будет достаточно создать объектную модель средствами вашего любимого CASE (Rational Rose, Together, PowerDesigner...) и сгенерировать из нее схему базы данных, используя подходящую стратегию отображения (mapping) (см. Приложение 1). Это и есть прямой инжиниринг (forward engineering). Но в реальной жизни чаще всего приходится начинать с доделки/переделки уже работающей системы, когда необходимо сохранить совместимость с имеющимся программным обеспечением на уровне базы данных, не меняя ее структуры. В этом случае вам предстоит обратная задача: взяв все тот же любимый CASE провести обратный инжиниринг (reverse engineering). В обоих случаях необходима либо простая интеграция ОРП с вашим CASE (более гибкий вариант), либо наличие CASE в составе самого ОРП (менее гибкий, но зато "все в одном флаконе"). И в обоих случаях необходимо иметь возможность вручную вмешаться на любой стадии генерации/регенерации кода.
  • Желательно с коммерческой лицензией и/или солидным поставщиком. Я не имею целью очередной "бессмысленный и беспощадный" спор на тему open source, дело не в бесплатности и открытости кода, который зачастую доступен и в коммерческих продуктах, а в том, к кому можно обратиться за поддержкой и быстро ее получить. Linux, MySQL и Mono хороши не потому, что бесплатные, а потому, что, несмотря на бесплатность, существуют фирмы, вкладывающие в них миллионы и отвечающие за их выпуск. Чего нельзя сказать об абсолютном большинстве других продуктов, пасущихся на www.sourceforge.net.

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

А мы тем временем взглянем, что нам предлагает рынок.

Краткий обзор ОРП

Длинный список ОРП (на англ.языке) вы можете увидеть на странице sharptoolbox.com и на многих других, которые можно найти посредством поиска в Интернет (google, yandex) с ключевыми словами "ORM .NET". К сожалению практически вся найденная вами информация будет на английском языке, поэтому если не хотите лишний раз напрягаться, то расслабьтесь и продолжайте чтение статьи.

 

Название D4Modelizer
Производитель, сайт DORLAC S.T, http://www.d4modelizer.com/
Лицензия свободно распространяемый, с открытым исходным кодом
Поддержка СУБД MS SQL Server, DB/2, Oracle, Sybase, MySQL, Access, Firebird, PostgreSQL

ОРП является простым кодогенератором, который создает набор C#-классов на основе схемы существующей базы данных. Имеется примитивный и нестабильно работающий интерфейс, где разработчик может модифицировать названия элементов, добавлять новые. Продукт сырой, создать схему существующей базы на PostgreSQL не удалось, для MSSQL была сгенерирована куча классов. Документация довольно скудная, четкой отработанной методики и контрольных примеров, уменьшающих порог вхождения нет. По всей видимости, автор создавал решение для своих нужд, а потом решил попробовать обобщить его для широкого круга.

 

Название Data Tier Modeler for .NET
Производитель, сайт Evaluant, http://www.evaluant.com/en/solutions/dtm/default.aspx
Лицензия Коммерческая, на установки
Поддержка СУБД MS SQL Server, DB/2, Oracle, MySQL, Access

Продукт французской фирмы представляет собой полное решение, обеспечивающее как интеграцию с существующими БД, так и создание новых на основе объектной модели. Качественная презентация, обширная документация и описание методики использования. Интегрируется с Visual Studio: отдельная закладка в project explorer служит для управления моделью. Интегрируется с существующими CASE на уровне XMI. Схема проекции описывается в виде XML, то есть при необходимости интеграции с существующей БД вы имеете возможность изменять параметры вручную. Требуется наследование от базовых классов фреймворка. Основным недостатком является схема лицензирования, при которой нужно платить за каждую установку приложения у клиента. Таким образом, данный продукт может представлять интерес скорее для внутрикорпоративных приложений, чем для тиражируемых.

 

Название DataObjects.NET
Производитель, сайт X-tensive, http://www.x-tensive.com/Products/DataObjects.NET/
Лицензия Коммерческая, на разработчика
Поддержка СУБД MS SQL Server, Oracle, SAP DB, Firebird/Interbase

Приятно увидеть в этом ряду продукцию отечественного производителя. ОРП поддерживает прямую и обратную разработку и весьма интересные дополнительные возможности, такие как полнотекстовый поиск (на основе MS Search для MS SQL Server или DotLucene - независимой от конкретной СУБД системы), систему безопасности схожую по принципам с NTFS, возможность выгрузки в т.н. offline layer - временное хранилище для обеспечения работы приложения вне сети с последующей синхронизацией, версионность объектов, поддержка более одного языка для значений атрибутов. Документация достаточно полная, однако презентация из 140 слайдов, которая рассчитана по словам самих разработчиков на 2 часа просмотра вряд ли может быть названа удачной находкой. Продукт нельзя отнести только к классу ОРП: по причине широкого функционала он ближе к каркасу разработки корпоративных приложений. Соответственно, если ваша задача умещается в рамки ОРП, то фреймворк такого уровня может оказаться излишне "тяжелым". Также в руководстве ничего не удалось найти на тему интеграции с CASE и UML.

 

Название eXpress Persistent Objects (XPO)
Производитель, сайт Developer Express, http://www.devexpress.com/products/NET/XPO/
Лицензия Коммерческая, на разработчика, исходный код доступен
Поддержка СУБД MS SQL Server, Access, MySQL, Oracle, Advanced Data Server, PostgreSQL

Компания Developer Express давно известна своим великолепным набором визуальных компонентов (eXtra grid, eXtra reports...) для сред Delphi и .NET. XPO в этом ряду выглядят не менее привлекательно. Продукт оставляет ощущение легкости, но не легковесности. Документация достаточна при своем небольшом объеме, порог вхождения для новичка низок, в поставку входит множество примеров. Интеграция с Visual Studio на уровне шаблонов и дизайнеров для компонентов. Схему проекции можно задавать как непосредственно в метаданных классов, так и в отдельном XML-файле, обеспечивая тем самым, использование одного и того же набора классов для работы с разными СУБД. Возможность проекции на хранимые процедуры (атрибуты отображаются на параметры) анонсирована в версии 2 (актуальная версия имеет номер 1.6), которая, однако, не спешит появится на свет.

Кроме функций ОРП реализована поддержка логического удаления объектов по принципу "мусорной корзины" с возможностью их восстановления. Хочется отметить хорошую поддержку как в новостной группе devexpress.public.dotnet.xpo на сервере компании news.devexpress.com, так и на форуме. Имеется обширная база знаний, на сайте опубликован ряд статей, освещающих рекомендуемые методы решения часто встречающихся ситуаций и проблем. Коллекции объектов без каких-либо ограничений подключаются как к стандартным сеткам (grids) в .NET, так и к собственным eXtra grids. Мое субъективное мнение об XPO благоприятное: с помощью документации и базы знаний прототип был собран за несколько часов, в то время как аналогичная работа для NHibernate заняла три дня, оставив больше вопросов, чем ответов. К числу недостатков можно отнести отсутствие готовых средств моделирования или интеграции с CASE, необходимость модификации БД (вручную или автоматически добавляются 2 служебные таблицы и по 2 поля в каждую таблицу). Неудачным решением мне кажется отсутствие языка запросов, условия выборки (where) конструируются путем создания массива объектов-выражений и связок.

 

Название LLBLGen Pro
Производитель, сайт http://www.llblgen.com
Лицензия Коммерческая, на разработчика
Поддержка СУБД MS SQL Server, Access, Oracle, Firebird/Intervase, DB2, MySQL

Продукт рассчитан в большей степени на обратный инжиниринг. Даже если вы создаете новое приложение, то рекомендуется начать процесс с проектирования базы данных, затем генератор создает вам слой прикладных объектов. В дальнейшем, вы сможете вносить изменения уже на уровне объектной модели: для этого разработчику предоставляется графический интерфейс, в котором он может добавлять/модифицировать элементы и управлять отображением (mapping). Продукт фактически создается и поддерживается единственным голландским разработчиком, в этом есть и плюсы: максимальное качество ответов на вопросы, единая непротиворечивая архитектура, так и минусы: риски остаться наедине с продуктом, если автор потеряет к нему интерес. Успешная истории использования LLBLGen нашими партнерами из Firstream (http://www.firstream.com) в достаточно большом проекте (портал финансовых транзакций типа WebMoney с широкими возможностями персонификации, 1,3 млн. клиентов, решение целиком создано на платформе Microsoft: ASP.NET, WebServices, MS SQL Server) позволяет утверждать, что продукт готов для промышленного использования в OLTP-приложениях. Интеграция с CASE отсутствует, имеется собственный интерфейс моделирования, отображающий артефакты в виде древовидных структур, что не всегда удобно по сравнению с диаграммой классов.

 

Название NEO (.NET Entity Objects)
Производитель, сайт http://neo.codehaus.org
Лицензия Свободно распространяемый, с открытым исходным кодом
Поддержка СУБД Любая через ADO.NET

Продукт поддерживается небольшой командой разработчиков, начальная версия была создана в 2003 году в процессе работы над программой для энергетической компании, развернутой позже во множестве филиалах, в ссылках указывается цифра 50 тысяч одновременно используемых объектов в памяти (С.Т.: видимо, имеется в виду кэш). Основной процесс разработки состоит в создании описания модели в виде XML-файла, но основе которого может быть сгенерированы как слой прикладных объектов, так и схема базы данных. К такому процессу напрашивается использование CASE вместо ручного кодирования, но никаких упоминаний об интеграции не было найдено, а своих инструментов моделирования не поставляется. Соответственно, возможен и обратный инжиниринг на основе существующей базы данных. К числу интересных возможностей также следует отнести наличие работы в отсоединенном от сети режиме, то есть поддерживается временное хранилище объектов, как и в DataObjects.NET. Декларированная работа с любой СУБД, имеющей ADO.NET-провайдер, с одной стороны является плюсом ввиду универсальности подхода. С другой стороны, по сравнению с продуктами, которые поддерживают несколько СУБД на основе абстрактного слоя и специфичных стратегий или адаптеров, взаимодействие с СУБД будет неоптимальным (фактически, это работа с чистыми DataSet вместо диалекта SQL) и не учитывающим специфику конкретной СУБД. Вдобавок, имея достаточный опыт оптимизации, я всегда настороженно отношусь к заявлениям вроде "поддержки любой СУБД".

 

Название ObjectMapper
Производитель, сайт MathSoft, http://www.objectmapper.com
Лицензия Коммерческая, бесплатный для некоммерческого использования
Поддержка СУБД MS SQL Server, Access

На самом деле, это не ОРП, а среда моделирования на основе UML, которая генерирует схему БД и схему отображения (mapping) для ОРП NHibernate, NPersist и Borland ECO II. Продукт пока "сырой", поддерживаются только MSSQL и Access, основной разработчик тоже один (Mats Helander). Пожалуй, это единственное на сегодня доступное средство моделирования для ОРП на .NET, поэтому выбор может стоять между "сырым", но бесплатным для внутренней разработки, ObjectMapper и совсем недешевыми CASE. В потенциале продукт может поддерживать все СУБД, которые поддерживают перечисленные выше ОРП, для которых он служит моделирующей надстройкой.

 

Название NHibernate
Производитель, сайт http://wiki.nhibernate.org/display/NH/Home
Лицензия Свободно распространяемый, с открытым исходным кодом
Поддержка СУБД MS SQL Server, Oracle, DB2, Access, MySQL, PostgreSQL, SQLite, Firebird

NHibernate является перенесенной на платформу .NET версией ОРП Hibernate для Java. Несомненным плюсом является зрелость своего Java-собрата по части концепций, архитектуры и алгоритмов, который с другой стороны является и минусом: "лобовой" перенос неоптимален, значит, часть кода переписывается с учетом специфики .NET, что означает новые ошибки и обычные проблемы "детского возраста". Версия для .NET по естественным причинам также обречена отставать от своего Java-аналога (в настоящее время .NET аналог соответствует версии 2.0.3, тогда как Java-разработчикам уже доступна версия 3). Поддерживается прямой и обратный инжиниринг, правда, только в ручном режиме.

В качестве недостатков следует отметить незрелость продукта, которая проявляется в скудной документации (рекомендуется читать ее полную версию для Java-аналога), плохой поддержке, отсутствии четкой и стабильной методики разработки. Весь опыт и "база знаний" пока концентрируются в нескольких разбросанных по сети статьях разработчиков, использовавших NHibernate, и паре не вполне наглядных примеров. Создание тестового приложения напоминало постоянное "хождение по граблям", при этом найти решение очередной проблемы занимало большое количество времени (многие часы поисков в сети). Никаких средств моделирования не поставляется, но в дополнительном пакете (contribution) есть утилита командной строки, которая по XML-файлу описания отображения генерирует либо схему БД, либо слой прикладных объектов.

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

 

Название Versant Open Access .NET (VOA)
Производитель, сайт Versant, http://www.versant.com/products/openaccess/dotnet
Лицензия Коммерческая, на разработчика
Поддержка СУБД MS SQL Server, Oracle, FastObjects

Этот продукт также является переносом на платформу .NET своей одноименной Java-версии. Поддерживается прямой и обратный инжиниринг. Хорошо интегрированный с Visual Studio, он позволяет визуально управлять (mapping designer) отображением и генерацией/модификацией схемы БД прямо из среды, однако, сами прикладные классы необходимо либо изначально писать вручную, либо генерировать из вашего любимого CASE, либо генерировать с помощью самого VOA на основе существующей базы данных.

К числу недостатков следует отнести небольшой спектр поддерживаемых СУБД, проблемы с управлением генерацией уникальных идентификаторов объектов (не поддерживается GUID), модификация кода ваших объектов на IL-уровне. Тем не менее, продукт активно развивается, на сайте опубликованы планы по устранению проблем в новой версии до конца этого года, но уже для платформы .NET 2.

Выводы

По естественным причинам, связанным с более поздним появлением платформы .NET, основные стандарты и решения вырабатываются в мире Java и переносятся в .NET. Поэтому на сегодняшний день рынок ОРП для .NET незрелый, имеется "зоопарк" продуктов, зачастую выполненных на уровне студенческих дипломных проектов. Большинство ОРП поддерживают MS SQL Server и Access, работа с другими СУБД вызывает определенные проблемы. Интеграция со средствами моделирования находится в состоянии зародыша. Среди лидеров пока еще неоформившегося рынка хотелось бы выделить Versant Open Access, XPO, LLBLGen Pro, DataObjects.NET и NHibernate. Использование перечисленных в статье средств может в некоторых случаях существенно уменьшить ваши затраты на разработку и внесение изменений, но риски, связанные с выбором инструмента, пока остаются высокими.

Приложение 1. Стратегии отображения, основные понятия и термины

Можно выделить три основные стратегии отображения объектов на реляционную схему БД. Подробнее см. статью А.Усова "ООП о реляционной модели"

  1. Хранение всех атрибутов в одной таблице
  2. Группировка общих атрибутов в одной таблице и разнесение уникальных атрибутов (подклассов) по связанным таблицам
  3. Представление каждого класса в виде отдельной таблицы

Стратегия 1 не относится собственно к реляционной модели и может рассматриваться разве что как средство оптимизации. Стратегии 2 и 3 используются CASE-средствами проектирования базы данных (ErWin, PowerDesigner) и обозначаются как "complete/incomplete subtyping" со схемой "roll-up" (стратегия 2, атрибуты подкласса в новой таблице) и "roll-down" (стратегия 3, наследуемые атрибуты добавляются к таблице суперкласса).

В ОРП, обеспечивающих выбор стратегии генерации схемы БД (например, JDO) обозначения несколько иные. Стратегия 1 называется "плоским отображением" (flat mapping), остальные стратегии реализуются либо при помощи "вертикального отображения" (стратегия 2, vertical mapping), либо "смешанного отображения" (стратегии 2 и 3, mixed mapping).

Сергей Тарасов, июнь 2005

Статья также опубликована в журнале ZDnet.ru

Комментарии

А броузером вы каким пользуетесь?

А броузером вы каким пользуетесь? IE? А я вот нет. А мессенжером msn? Я вот по старинке icq. А intellisense в студии родной или Resharper? А unit-тесты встроенные или nunit? А сколько народу на cvn и subversion сидит и не думает на vss/tfs переходить? ...