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

Question

Я видел в своем учебнике для школы, что многие операции объединения никогда не оптимизировали таблицу справа от объединения и только слева. Например, чтобы найти имя сотрудника, управляющего отделом базы данных, вы должны сделать это:
? _name (? _{Mgr_ssn} (? _{Dname = 'Database) '} (отдел)) ⨝ _{Mgr_ssn = ssn} сотрудник)

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

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

Answer 1

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

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

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

Answer 2

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

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

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