Три манифеста баз данных ретроспектива и перспективы


         

Предложения, касающиеся увеличения функциональных возможностей СУБД - часть 2


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

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

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


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