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



         

Проблема частичных объектов и парадокс времени загрузки - часть 3


Это значит, что в системе приходится выбирать один из трех неудобных вариантов: (1) потребовать, чтобы в объектах Person могли содержаться поля, допускающие наличие неопределенных значений, независимо от возможных ограничений прикладной области; (2) возвращать объекты Person, содержащие все данные, присущие людям; (3) обеспечить некоторую разновидность загрузки по требованию, которая будет заполнять поля объектов только тогда, когда к ним производится доступ, возможно, косвенный, через вызов метода.

(Заметим, что в некоторых объектных языках, таких как ECMAScript, объекты представляются не так, как в языках, основанных на классах (например, C# и Java), и в результате в таких языках разрешается возвращать объекты, содержащие переменное число полей. Однако, с другой стороны, этот подход применяется лишь в немногих языках, он не применяется даже в любимом всеми и являющемся образцом для подражания динамическом языке Ruby, и пока такие языки не станут широко распространенными, их обсуждение в данном контексте не имеет смысла.)

Для большинства слоев ОР-отображения это означает, что объекты и/или поля объектов должны выбираться в манере отложенной (lazy) загрузки с предоставлением данных в полях по требованию, поскольку в обсуждаемом сценарии выборка всех полей всех объектов/отношений Person, «очевидно» привела бы в громадной потере пропускной способности. Обычно имеет смысл выбирать полный набор полей при доступе к любому еще на заполненному данными полю. (Это подход предпочтительнее подхода с выборкой данных отдельных требуемых полей, поскольку он с меньшей вероятностью приводит к «проблеме N+1-го запроса», когда при выборке всех данных объекта требуются один запрос для выборки первичного ключа плюс N запросов для выборки данных всех остальных полей по одиночке. При подходе с выборкой данных индивидуальных полей минимизируется потребление пропускной способности для выборки данных – данные неиспользуемых полей не выбираются, – но, очевидным образом, не удается минимизировать число сетевых взаимодействий.)

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




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