Оптимизация реляционной алгебры

Question

В моем учебнике для школы я видел, что многие операции соединения никогда не оптимизировали таблицу справа от соединения и только слева. Например, чтобы найти имя сотрудника, управляющего отделом базы данных, вы могли бы сделать это:
_имя ( _{Mgr_ssn} ( _{Dname = 'База данных'} (департамент)) ⨝ _{Mgr_ssn = ПЛА} Сотрудник)

Так мне интересно, если это будет одинаково правильно сделать что-то вроде:
_имя ( _{Mgr_ssn} ( _{Dname = 'База данных'} (департамент)) ⨝ _{Mgr_ssn = ПЛА} ( _{ssn, имя} Сотрудник))

Это предполагает, что Employee имеет много других атрибутов. При этом я думаю, что система будет экономить время, не беспокоясь о присоединении ко всем другим атрибутам Employee, когда в конце концов они будут проецироваться в любом случае. Я никогда не видел такой проекции с правой стороны соединения раньше, и мне интересно, приемлемо ли это и/или нет.

Answer 1

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

Пространство поиска всех параметров экспоненциально, поэтому оптимизаторы хотят быстро найти приемлемые решения (оптимизаторы не находят лучшего решения, стараются избегать худших).

P.S. Причиной использования левого глубокого соединения является то, что он позволяет конвейерно обрабатывать результаты без необходимости записывать их на диск, что экономит операции ввода-вывода.

Answer 2

Любой надежный оптимизатор запросов будет сжимать соответствующие ограничения, а иногда и проекции, чтобы минимизировать обрабатываемые данные. И поскольку оптимизатор будет делать это автоматически, и результат будет идентичным, нет особой необходимости оптимизировать выражение в реляционной алгебре.

В последовательности объединения двух таблиц, как это, не ясно, что будет полезно сформировать проекцию перед присоединением к отделу; вероятная последовательность обработки найдет (возможно, один) отдел с Dname = 'Database', а затем найдет одну строку в Employee с E.SSN = D.Mgr_SSN. Однако, если подвыражение использовалось несколько раз, это может стоить того.

Я также отмечаю, что дизайн ужасен - вы никогда не должны использовать что-либо столь же чувствительное, как SSN, как поле соединения в дизайне базы данных. Команда PCI подойдет! Но, возможно, имена - похмелье из более мягких времен, давно прошедших, но контент является сгенерированным суррогатом, а реальный SSN хранится в Employee.RealSSN (который может даже быть зашифрован, чтобы гарантировать, что неавторизованный не видит его, хотя установка разрешений правильно в столбце, так что только санкционированный может выбрать его также эффективно).