Классика баз данных - статьи



         

Проблема механизма выборки данных - часть 4


Query q = new Query();

Field lastNameFieldFromPerson =
Person.class.getDeclaredField("lastName");

q.From(Person.class).Where(new

EqualsCriteria(lastNameFieldFromPerson, "Smith"));

ObjectCollection oc = QueryExecutor.execute(q);

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

Поэтому следующая задача состоит в построении подхода «Query-By-Language», в котором создается новый язык, похожий на SQL, но в чем-то его «превосходящий», для поддержки сложных и мощных запросов, обычно поддерживаемых SQL. Примерами такого языка являются OQL и HQL. Здесь проблемой является то, что эти языки часто являются подмножествами SQL, и поэтому они не обладают полной мощностью SQL. Более важно то, что в слое ОР-отображения теперь теряется важный «выигрышный момент» – мантра «объекты и только объекты», которая породила этот подход. Использование SQL-подобного языка – это почти использование самого SQL, и как такой язык может быть более «объектным»? Хотя разработчикам может не потребоваться осведомленность о физической схеме модели данных (интерпретатор/исполнитель языка запросов может произвести упомянутое выше отображение), разработчикам понадобится знание того, как в языке представляются ассоциации и свойства, и подмножество объектных возможностей внутри языка запросов. Например, будет ли возможным написать следующее?

SELECT Person p1, Person p2

FROM Person

WHERE p1.getSpouse() == null

AND p2.getSpouse() == null

AND p1.isThisAnAcceptableSpouse(p2)

AND p2.isThisAnAcceptableSpouse(p1);

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


Содержание  Назад  Вперед