В этом контексте достаточно было
В этом контексте достаточно было бы
открыть видимость только для компилятора запросов, т.е.
фактически запретить переопределять такие переменные в
подклассах. С точки зрения пользователя такие атрибуты выглядели
бы как методы без параметров, возвращающие значение
соответствующего типа. С нашей точки зрения, лучше было бы
сохранить строгую инкапсуляцию объектов (чтобы избавить
приложение от критической зависимости от реализации) и обеспечить
возможности тщательного проектирования схемы ООБД с учетом
потребностей оптимизации запросов.
Общий подход к предоптимизации условия выборки для одного
(супер)класса объектов может быть следующим (мы предполагаем, что
условия формулируются с использованием логики предикатов первого
порядка без кванторов; в предикатах могут использоваться методы
соответствующего класса, константы и операции сравнения):
Шаг А: Преобразовать логическую формулу условия к конъюнктивной нормальной форме (КНФ). Мы не останавливаемся на способе
выбора конкретной КНФ, но естественно, должна быть выбрана "хорошая" КНФ (например, содержащая максимальное число атомарных
конъюнктов).
Шаг B: Для каждого конъюнкта, включающего методы только с
известной во время компиляции телом, заменить вызовы методов на
их тела с подставленными параметрами. (Для простоты будем
предполагать, что параметры не содержат вызовов функций или
методов других объектов.)
Шаг C: Для каждого такого конъюнкта произвести все возможные
упрощения, т.е. вычислить все, что можно вычислить в статике.
Хотя в общем виде эта задача является очень сложной, при разумном
проектировании ООБД в число методов должны будут войти методы с
предельно простой реализацией, задавать условия на которых будет
очень естественно. Такие условия будут упрощаться очень
эффективно.
Шаг D: Если теперь появились конъюнкты, представляющие собой
простые предикаты сравнения на основе переменных состояния и
констант, использовать эти конъюнкты для выработки оптимального
плана выполнения запроса.
Содержание Назад Вперед